<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="UTF-8">
	<title>SonarQube Vulnerability Report</title>
	<style>
		/*
	The sss stylesheet is released under the MIT license.
	<https://github.com/Thiht/sss>
	*/
		pre,
		td,
		th {
			padding: 5px 10px
		}

		code,
		hr,
		pre,
		thead {
			background: #EEE
		}

		body {
			color: #333;
			font-family: 'Segoe UI', 'Lucida Grande', Helvetica, sans-serif;
			line-height: 1.5;
		}

		div.summup {
			max-width: 800px;
			margin: 50px auto;
		}
		div.detail {
			padding: 20px;
		}

		h1,
		h2,
		h3,
		h4,
		h5,
		h6 {
			font-weight: 400;
			line-height: 1em;
			margin: 20px 0
		}

		h1 {
			font-size: 2.25em
		}

		h2 {
			font-size: 1.75em
		}

		h3 {
			font-size: 1.5em
		}

		h4,
		h5,
		h6 {
			font-size: 1.25em
		}

		a {
			color: #08C;
			text-decoration: none
		}

		a:focus,
		a:hover {
			text-decoration: underline
		}

		a:visited {
			color: #058
		}

		img {
			max-width: 100%
		}

		li+li {
			margin-top: 3px
		}

		dt {
			font-weight: 700
		}

		code {
			font-family: Consolas, "Lucida Console", monospace;
			padding: 1px 5px
		}

		pre {
			white-space: pre-wrap
		}

		pre code {
			padding: 0
		}

		blockquote {
			border-left: 5px solid #EEE;
			margin: 0;
			padding: 0 10px
		}

		table {
			border-collapse: collapse;
			width: 100%
		}

		table+table {
			margin-top: 1em
		}

		thead {
			text-align: left
		}

		td,
		th {
			border: 1px solid #EEE
		}
		td.component{
			word-break: break-all;
		}

		hr {
			border: 0;
			height: 1px
		}
	</style>
	<style>
		.banner {
			text-align: center;
		}

		canvas {
			display: block;
			margin: 10px auto;
		}
	</style>
</head>

<body>
	<div class=summup>
		<!-- insert your company banner here -->
		<!--
		<p class="banner">
			<a href="https://www.soprasteria.com/" target="_blank">
				<img src="https://upload.wikimedia.org/wikipedia/en/thumb/0/02/Sopra_Steria_logo.svg/1280px-Sopra_Steria_logo.svg.png" alt="Sopra Steria" height="50">
			</a>
		</p>
		-->

		<h1>SonarQube Vulnerability Report</h1>

		<dl>
			<dt>Report Generated On</dt>
			<dd>Thu Aug 01 2019</dd>

			<dt>Project Name</dt>
			<dd>java tomcat</dd>

			<dt>Application</dt>
			<dd>tomcat</dd>

			<dt>Release</dt>
			<dd>1.0.0</dd>

			<dt>Delta analysis</dt>
			<dd>No</dd>

			
		</dl>

		<h2>Summary of the Detected Vulnerabilities</h2>
		<table>
			<thead>
				<tr>
					<th></th>
					<th>Severity</th>
					<th>Number of Issues</th>
				</tr>
			</thead>
			<tbody>
				<tr>
					<td style="background-color:#2c3e50"></td>
					<td>BLOCKER</td>
					<td>3</td>
				</tr>
				<tr>
					<td style="background-color: #d43223"></td>
					<td>CRITICAL</td>
					<td>1</td>
				</tr>
				<tr>
					<td style="background-color: #f39c12"></td>
					<td>MAJOR</td>
					<td>0</td>
				</tr>
				<tr>
					<td style="background-color: #319ddb"></td>
					<td>MINOR</td>
					<td>2</td>
				</tr>
			</tbody>
		</table>

		

		<canvas id="vulnerabilitiesPieChart" width="200" height="200"></canvas>
	</div>

	<div class=detail>
		<h2>Detail of the Detected Vulnerabilities</h2>
		<table>
			<thead>
				<tr>
					<th>Rule</th>
					<th>Severity</th>
					<th>Component</th>
					<th>Line</th>
					<th>Description</th>
					<th>Message</th>
					<th style="display:none;">Key</th>
				</tr>
			</thead>
			<tbody>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/DataSourceFactory.java</td>
					<td>66</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PASSWORD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWK40IMu-pl6AHs22MnV</td>
				</tr>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolUtilities.java</td>
					<td>25</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PASSWORD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWK40INQ-pl6AHs22Mod</td>
				</tr>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">java/org/apache/tomcat/websocket/Constants.java</td>
					<td>60</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PWD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWK40IKV-pl6AHs22MkD</td>
				</tr>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S2077">squid:S2077</a></td>
					<td>CRITICAL</td>
					<td class="component">modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PooledConnection.java</td>
					<td>543</td>
					<td>/</td>
					<td>Use a variable binding mechanism to construct this query instead of concatenation.</td>
					<td style="display:none;">AWK40INU-pl6AHs22Mog</td>
				</tr>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S1444">squid:S1444</a></td>
					<td>MINOR</td>
					<td class="component">java/org/apache/tomcat/jni/Library.java</td>
					<td>109</td>
					<td>&#34;public static&#34; fields should be constant</td>
					<td>Make this &#34;public static APR_MINOR_VERSION&#34; field final</td>
					<td style="display:none;">AWK40H7B-pl6AHs22MKy</td>
				</tr>
				
				<tr>
					<td><a href="https://sonarcloud.io/coding_rules#rule_key=squid:S1148">squid:S1148</a></td>
					<td>MINOR</td>
					<td class="component">java/org/apache/el/lang/FunctionMapperImpl.java</td>
					<td>162</td>
					<td>Throwable.printStackTrace(...) should not be called</td>
					<td>Use a logger to log this exception.</td>
					<td style="display:none;">AWK40Hpg-pl6AHs22Lt9</td>
				</tr>
				
				
			</tbody>
		</table>

		

		<h3>Known Security Rules</h3>
		<table style="table-layout: fixed; word-wrap: break-word">
			<thead>
				<tr>
					<th>Rule</th>
					<th>Description</th>
				</tr>
			</thead>
			<tbody>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2658">squid:S2658</a>
					</td>
					<td>
						<details>
							<p>Dynamically loaded classes could contain malicious code executed by a static class initializer. I.E. you wouldn't even have to instantiate or
explicitly invoke methods on such classes to be vulnerable to an attack.</p>
<p>This rule raises an issue for each use of dynamic class loading.</p>
<h2>Noncompliant Code Example</h2>
<pre>
String className = System.getProperty("messageClassName");
Class clazz = Class.forName(className);  // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/470.html">MITRE, CWE-470</a> - Use of Externally-Controlled Input to Select Classes or Code
  ('Unsafe Reflection') </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3369">squid:S3369</a>
					</td>
					<td>
						<details>
							<p>Websphere, Tomcat, and JBoss web servers allow the definition of role-based access to servlets. It may not be granular enough for your purposes,
but it's a start, and should be used at least as a base.</p>
<p>This rule raises an issue when a <em>web.xml</em> file has no <code>&lt;security-constraint&gt;</code> elements.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/284.html">MITRE, CWE-284</a> - Improper Access Control </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2039">squid:S2039</a>
					</td>
					<td>
						<details>
							<p>Failing to explicitly declare the visibility of a member variable could result it in having a visibility you don't expect, and potentially leave it
open to unexpected modification by other classes. </p>
<h2>Noncompliant Code Example</h2>
<pre>
class Ball {
    String color="red";  // Noncompliant
}
enum A {
  B;
  int a;
}
</pre>
<h2>Compliant Solution</h2>
<pre>
class Ball {
    private String color="red";  // Compliant
}
enum A {
  B;
  private int a;
}
</pre>
<h2>Exceptions</h2>
<p>Members annotated with Guava's <code>@VisibleForTesting</code> annotation are ignored, as it indicates that visibility has been purposely relaxed
to make the code testable.</p>
<pre>
class Cone {
  @VisibleForTesting
  Logger logger; // Compliant
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5135">javasecurity:S5135</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters, POST data payloads or cookies should always be considered untrusted and tainted. Deserialization based
on data supplied by the user could result in two types of attacks:</p>
<ul>
  <li> Remote code execution attacks, where the structure of the serialized data is changed to modify the behavior of the object being unserialized.
  </li>
  <li> Parameter tampering attacks, where data is modified to escalate privileges or change for example quantity or price of products. </li>
</ul>
<p>The problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Instead of using a native data interchange format, use a safe, standard format such as JSON. </li>
  <li> To ensure integrity is not compromised, add a digital signature to the serialized data that is validated before deserialization. </li>
  <li> As a last resort, restrict deserialization to be possible only to specific, whitelisted classes. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public class RequestProcessor {
  protected void processRequest(HttpServletRequest request) {
    ServletInputStream sis = request.getInputStream();
    ObjectInputStream ois = new ObjectInputStream(sis);
    Object obj = ois.readObject(); // Noncompliant
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class SecureObjectInputStream extends ObjectInputStream {
  // Constructor here

  @Override
  protected Class&lt;?&gt; resolveClass(ObjectStreamClass osc) throws IOException, ClassNotFoundException {
    // Only deserialize instances of AllowedClass
    if (!osc.getName().equals(AllowedClass.class.getName())) {
      throw new InvalidClassException("Unauthorized deserialization", osc.getName());
    }
    return super.resolveClass(osc);
  }
}

public class RequestProcessor {
  protected void processRequest(HttpServletRequest request) {
    ServletInputStream sis = request.getInputStream();
    SecureObjectInputStream sois = new SecureObjectInputStream(sis);
    Object obj = sois.readObject();
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization">OWASP Top 10 2017 Category A8</a> - Insecure Deserialization
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/134.html">MITRE, CWE-134</a> - Use of Externally-Controlled Format String </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/502.html">MITRE, CWE-502</a> - Deserialization of Untrusted Data </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5334">javasecurity:S5334</a>
					</td>
					<td>
						<details>
							<p>Applications that execute code dynamically should neutralize any externally-provided values used to construct the code. Failure to do so could
allow an attacker to execute arbitrary code. This could enable a wide range of serious attacks like accessing/modifying sensitive information or gain
full system access.</p>
<p>The mitigation strategy should be based on whitelisting of allowed values or casting to safe types.</p>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String input = req.getParameter("input");

  ScriptEngineManager manager = new ScriptEngineManager();
  ScriptEngine engine = manager.getEngineByName("JavaScript");
  engine.eval(input); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String input = req.getParameter("input");

  // Match the input against a whitelist
  if (!whiteList.contains(input))
    throw new IOException();

  ScriptEngineManager manager = new ScriptEngineManager();
  ScriptEngine engine = manager.getEngineByName("JavaScript");
  engine.eval(input);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/94.html">MITRE, CWE-94</a> - Improper Control of Generation of Code ('Code Injection') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/95.html">MITRE, CWE-95</a> - Improper Neutralization of Directives in Dynamically Evaluated
  Code ('Eval Injection') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S3649">javasecurity:S3649</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing SQL queries directly from tainted data
enables attackers to inject specially crafted values that change the initial meaning of the query itself. Successful SQL injection attacks can read,
modify, or delete sensitive information from the database and sometimes even shut it down or execute arbitrary operating system commands.</p>
<p>Typically, the solution is to rely on prepared statements rather than string concatenation to inject tainted data into SQL queries, which ensures
that they will be properly escaped.</p>
<p>This rule supports: JDBC, Java EE Entity Manager, Spring Framework, Hibernate, JDO, Android Database, Apache Torque, Rapidoid.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, java.sql.Connection connection) throws SQLException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String query = "SELECT * FROM users WHERE user = '" + user + "' AND pass = '" + pass + "'"; // Unsafe

  // If the special value "foo' OR 1=1 --" is passed as either the user or pass, authentication is bypassed
  // Indeed, if it is passed as a user, the query becomes:
  // SELECT * FROM users WHERE user = 'foo' OR 1=1 --' AND pass = '...'
  // As '--' is the comment till end of line syntax in SQL, this is equivalent to:
  // SELECT * FROM users WHERE user = 'foo' OR 1=1
  // which is equivalent to:
  // SELECT * FROM users WHERE 1=1
  // which is equivalent to:
  // SELECT * FROM users

  java.sql.Statement statement = connection.createStatement();
  java.sql.ResultSet resultSet = statement.executeQuery(query); // Noncompliant
  return resultSet.next();
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, java.sql.Connection connection) throws SQLException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String query = "SELECT * FROM users WHERE user = ? AND pass = ?"; // Safe even if authenticate() method is still vulnerable to brute-force attack in this specific case

  java.sql.PreparedStatement statement = connection.prepareStatement(query);
  statement.setString(1, user); // Will be properly escaped
  statement.setString(2, pass);
  java.sql.ResultSet resultSet = statement.executeQuery();
  return resultSet.next();
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/564.html">MITRE, CWE-564</a> - SQL Injection: Hibernate </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/20.html">MITRE, CWE-20</a> - Improper Input Validation </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/943.html">MITRE, CWE-943</a> - Improper Neutralization of Special Elements in Data Query Logic
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/PgIRAg">CERT, IDS00-J.</a> - Prevent SQL injection </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S2078">roslyn.sonaranalyzer.security.cs:S2078</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters should always be considered as untrusted and tainted. Constructing LDAP names or search filters directly
from tainted data enables attackers to inject specially crafted values that changes the initial meaning of the name or filter itself. Successful LDAP
injections attacks can read, modify or delete sensitive information from the directory service.</p>
<p>Within LDAP names, the special characters <code>' '</code>, <code>'#'</code>, <code>'"'</code>, <code>'+'</code>, <code>','</code>,
<code>';'</code>, <code>'&lt;'</code>, <code>'&gt;'</code>, <code>'\'</code> and <code>null</code> must be escaped according to RFC 4514, for example
by replacing them with the backslash character <code>'\'</code> followed by the two hex digits corresponding to the ASCII code of the character to be
escaped. Similarly, LDAP search filters must escape a different set of special characters (including but not limited to <code>'*'</code>,
<code>'('</code>, <code>')'</code>, <code>'\'</code> and <code>null</code>) according to RFC 4515.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class LDAPInjection : Controller
{
  public DirectorySearcher ds { get; set; }

  // GET /LDAPInjection/Authenticate
  public IActionResult Authenticate(string user, string pass)
  {
    ds.Filter = "(&amp;(uid=" + user + ")(userPassword=" + pass + "))"; // Noncompliant

    // If the special value "*)(uid=*))(|(uid=*" is passed as user, authentication is bypassed
    // Indeed, if it is passed as a user, the filter becomes:
    // (&amp;(uid=*)(uid=*))(|(uid=*)(userPassword=...))
    // as uid=* match all users, it is equivalent to:
    // (|(uid=*)(userPassword=...))
    // again, as uid=* match all users, the filter becomes useless

    return Content(ds.FindOne() != null ? "success" : "fail");
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class LDAPInjection : Controller
{
  public DirectorySearcher ds { get; set; }

  // GET /LDAPInjection/Authenticate
  public IActionResult Authenticate(string user, string pass)
  {
    // Restrict the username and password to letters only
    if (!Regex.IsMatch(user, "^[a-zA-Z]+$") || !Regex.IsMatch(pass, "^[a-zA-Z]+$"))
    {
      return BadRequest();
    }

    ds.Filter = "(&amp;(uid=" + user + ")(userPassword=" + pass + "))"; // Now safe
    return Content(ds.FindOne() != null ? "success" : "fail");
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4514.txt">RFC 4514</a> - LDAP: String Representation of Distinguished Names </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4515.txt">RFC 4515</a> - LDAP: String Representation of Search Filters </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/90">MITRE CWE-90</a> - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP
  Injection') </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/CgLEAw">CERT, IDS54-J.</a> - Prevent LDAP injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S3649">roslyn.sonaranalyzer.security.cs:S3649</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing SQL or SQL-like queries directly from
tainted data enables attackers to inject specially crafted values that change the initial meaning of the query itself. Successful database query
injection attacks can read, modify, or delete sensitive information from the database and sometimes even shut it down or execute arbitrary operating
system commands.</p>
<p>Typically, the solution is to rely on prepared statements rather than string concatenation to inject tainted data into database queries, which
ensures that they will be properly escaped.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class SqlInjection : Controller
{
  private readonly UsersContext _context;

  public SqlInjection(UsersContext context)
  {
    _context = context;
  }

  // GET /SqlInjection/Authenticate
  public IActionResult Authenticate(string user)
  {
    var query = "SELECT * FROM Users WHERE Username = '" + user + "'"; // Unsafe
    var userExists = _context.Users.FromSql(query).Any(); // Noncompliant

    // An attacker can bypass authentication by setting user to this special value
    user = "' or 1=1 or ''='";

    return Content(userExists ? "success" : "fail");
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class SqlInjection : Controller
{
  private readonly UsersContext _context;

  public SqlInjection(UsersContext context)
  {
    _context = context;
  }

  // GET /SqlInjection/Authenticate
  public IActionResult Authenticate(string user)
  {
    var query = "SELECT * FROM Users WHERE Username = {0}"; // Safe
    var userExists = _context.Users.FromSql(query, user).Any();
    return Content(userExists ? "success" : "fail");
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/564.html">MITRE, CWE-564</a> - SQL Injection: Hibernate </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/20.html">MITRE, CWE-20</a> - Improper Input Validation </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/943.html">MITRE, CWE-943</a> - Improper Neutralization of Special Elements in Data Query Logic
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/PgIRAg">CERT, IDS00-J.</a> - Prevent SQL injection </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S2091">roslyn.sonaranalyzer.security.cs:S2091</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing XPath expressions directly from tainted
data enables attackers to inject specially crafted values that changes the initial meaning of the expression itself. Successful XPath injection
attacks can read sensitive information from XML documents.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class XPathInjection : Controller
{
  public XmlDocument doc { get; set; }

  // GET /XPathInjection/Authenticate
  public IActionResult Authenticate(string user, string pass)
  {
    String expression = "/users/user[@name='" + user + "' and @pass='" + pass + "']"; // Unsafe

    // An attacker can bypass authentication by setting user to this special value
    user = "' or 1=1 or ''='";

    return Content(doc.SelectSingleNode(expression) != null ? "success" : "fail"); // Noncompliant
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class XPathInjection : Controller
{
  public XmlDocument doc { get; set; }

  // GET /XPathInjection/Authenticate
  public IActionResult Authenticate(string user, string pass)
  {
    // Restrict the username and password to letters only
    if (!Regex.IsMatch(user, "^[a-zA-Z]+$") || !Regex.IsMatch(pass, "^[a-zA-Z]+$"))
    {
      return BadRequest();
    }

    String expression = "/users/user[@name='" + user + "' and @pass='" + pass + "']"; // Now safe
    return Content(doc.SelectSingleNode(expression) != null ? "success" : "fail");
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/643">MITRE, CWE-643</a> - Improper Neutralization of Data within XPath Expressions </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/BwLEAw">CERT, IDS53-J.</a> - Prevent XPath Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S2631">phpsecurity:S2631</a>
					</td>
					<td>
						<details>
							<p>Evaluating regular expressions against input strings can be an extremely CPU-intensive task. For example, a specially crafted regular expression
such as <code>(a+)++</code> will take several seconds to evaluate the input string,&nbsp;<code>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!</code>. The problem is
that every additional "<code>a"</code> added to the input doubles the time required to evaluate the regex. However, the equivalent regular expression,
<code>a</code> (without grouping), is efficiently evaluated in milliseconds and scales linearly with the input size.</p>
<p>Evaluating user-provided strings as regular expressions opens the door for Denial Of Service attacks. In the context of a web application,
attackers can force the web server to spend all of its resources evaluating regular expressions thereby making the service inaccessible to genuine
users.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$regex = $_GET["regex"];
$input = $_GET["input"];

// Enables attackers to force the web server to evaluate
// regex such as "(a+)+" on inputs such as "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!"

preg_grep ( $regex, $input ); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$input = $_GET["input"];

preg_grep ( "a+", $input ); // Compliant - use a safe hardcoded regex
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/400">MITRE, CWE-400</a> - Uncontrolled Resource Consumption </li>
  <li> <a href="https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS">OWASP Regular expression Denial of Service - ReDoS</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5135">phpsecurity:S5135</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters, POST data payloads or cookies should always be considered untrusted and tainted. Deserialization based
on data supplied by the user could result in two types of attacks:</p>
<ul>
  <li> Remote code execution attacks, where the structure of the serialized data is changed to modify the behavior of the object being unserialized.
  </li>
  <li> Parameter tampering attacks, where data is modified to escalate privileges or change for example quantity or price of products. </li>
</ul>
<p>The problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Instead of using a native data interchange format, use a safe, standard format such as JSON. </li>
  <li> To ensure integrity is not compromised, add a digital signature to the serialized data that is validated before deserialization. </li>
  <li> As a last resort, restrict deserialization to be possible only to specific, whitelisted classes. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
$data = $_GET["data"];
$object = unserialize($data);
// ...
</pre>
<h2>Compliant Solution</h2>
<pre>
$data = $_GET["data"];

list($hash, $data) = explode('|', $data, 2);
$hash_confirm = hash_hmac("sha256", $data, "secret-key");

// Confirm that the data integrity is not compromised
if ($hash === $hash_confirm) {
  $object = unserialize($data);
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization">OWASP Top 10 2017 Category A8</a> - Insecure Deserialization
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/134.html">MITRE, CWE-134</a> - Use of Externally-Controlled Format String </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/502.html">MITRE, CWE-502</a> - Deserialization of Untrusted Data </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S2078">phpsecurity:S2078</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters should always be considered as untrusted and tainted. Constructing LDAP names or search filters directly
from tainted data enables attackers to inject specially crafted values that changes the initial meaning of the name or filter itself. Successful LDAP
injections attacks can read, modify or delete sensitive information from the directory service.</p>
<p>Within LDAP names, the special characters <code>' '</code>, <code>'#'</code>, <code>'"'</code>, <code>'+'</code>, <code>','</code>,
<code>';'</code>, <code>'&lt;'</code>, <code>'&gt;'</code>, <code>'\'</code> and <code>null</code> must be escaped according to RFC 4514, for example
by replacing them with the backslash character <code>'\'</code> followed by the two hex digits corresponding to the ASCII code of the character to be
escaped. Similarly, LDAP search filters must escape a different set of special characters (including but not limited to <code>'*'</code>,
<code>'('</code>, <code>')'</code>, <code>'\'</code> and <code>null</code>) according to RFC 4515.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$user = $_GET["user"];
$pass = $_GET["pass"];

$filter = "(&amp;(uid=" . $user . ")(userPassword=" . $pass . "))"; // Unsafe

$ds = ...
$basedn = "o=My Company, c=US";

$sr = ldap_list($ds, $basedn, $filter); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
function sanitize_ldap_criteria($val) {
  $val = str_replace(['\\', '*', '(', ')'], ['\5c', '\2a', '\28', '\29'], $val);
  for ($i = 0; $i&lt;strlen($val); $i++) {
    $char = substr($val, $i, 1);
    if (ord($char)&lt;32) {
      $hex = dechex(ord($char));
      if (strlen($hex) == 1) $hex = '0' . $hex;
      $val = str_replace($char, '\\' . $hex, $val);
    }
  }
  return $val;
}

$user = sanitize_ldap_criteria( $_GET["user"] );
$pass = sanitize_ldap_criteria( $_GET["pass"] );

$filter = "(&amp;(uid=" . $user . ")(userPassword=" . $pass . "))"; // Safe

$ds = ...
$basedn = "o=My Company, c=US";

$sr = ldap_list($ds, $basedn, $filter);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4514.txt">RFC 4514</a> - LDAP: String Representation of Distinguished Names </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4515.txt">RFC 4515</a> - LDAP: String Representation of Search Filters </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/90">MITRE CWE-90</a> - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP
  Injection') </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/CgLEAw">CERT, IDS54-J.</a> - Prevent LDAP injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5335">phpsecurity:S5335</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters, POST data payloads or cookies should always be considered untrusted and tainted. Constructing include
statements based on data supplied by the user could enable an attacker to control which files are included. If the attacker has the ability to upload
files to the system, then arbitrary code could be executed. This could enable a wide range of serious attacks like accessing/modifying sensitive
information or gain full system access.</p>
<p>The mitigation strategy should be based on whitelisting of allowed values or casting to safe types.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$filename = $_GET["filename"];
include $filename . ".php";
</pre>
<h2>Compliant Solution</h2>
<pre>
$filename = $_GET["filename"];
if (in_array($filename, $whitelist)) {
  include $filename . ".php";
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/97.html">MITRE, CWE-97</a> - Improper Neutralization of Server-Side Includes (SSI) Within a Web
  Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/98.html">MITRE, CWE-98</a> - Improper Control of Filename for Include/Require Statement in PHP
  Program ('PHP Remote File Inclusion') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/829.html">MITRE, CWE-829</a> - Inclusion of Functionality from Untrusted Control Sphere </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S2076">phpsecurity:S2076</a>
					</td>
					<td>
						<details>
							<p>Applications that execute operating system commands or execute commands that interact with the underlying system should neutralize any
externally-provided values used in those commands. Failure to do so could allow an attacker to include input that executes unintended commands or
exposes sensitive data.</p>
<p>The mitigation strategy should be based on whitelisting of allowed characters or commands.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$binary = $_GET["binary"];

// If the value "/sbin/shutdown" is passed as binary and the web server is running as root,
// then the machine running the web server will be shut down and become unavailable for future requests

exec( $binary ); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$binary = $_GET["binary"];

// Restrict to binaries within the current working directory whose name only contains letters
$pattern = "[a-zA-Z]++";
if ( preg_match($pattern, $binary) ) {
  exec( $binary ); // Compliant
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/78">MITRE, CWE-78</a> - Improper Neutralization of Special Elements used in an OS Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/88">MITRE, CWE-88</a> - Argument Injection or Modification </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5334">phpsecurity:S5334</a>
					</td>
					<td>
						<details>
							<p>Applications that execute code dynamically should neutralize any externally-provided values used to construct the code. Failure to do so could
allow an attacker to execute arbitrary code. This could enable a wide range of serious attacks like accessing/modifying sensitive information or gain
full system access.</p>
<p>The mitigation strategy should be based on whitelisting of allowed values or casting to safe types.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$data = $_GET["data"];
eval("echo \$data;");
</pre>
<h2>Compliant Solution</h2>
<pre>
$data = $_GET["data"];
if (in_array($data, $whitelist)) {
  eval("echo \$data;");
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/94.html">MITRE, CWE-94</a> - Improper Control of Generation of Code ('Code Injection') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/95.html">MITRE, CWE-95</a> - Improper Neutralization of Directives in Dynamically Evaluated
  Code ('Eval Injection') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S3649">phpsecurity:S3649</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing SQL queries directly from tainted data
enables attackers to inject specially crafted values that change the initial meaning of the query itself. Successful SQL injection attacks can read,
modify, or delete sensitive information from the database and sometimes even shut it down or execute arbitrary operating system commands.</p>
<p>Typically, the solution is to rely on the prepared statements rather than string concatenation, which ensures that user provided data will be
properly escaped.</p>
<p>This rule supports: Native Database Extensions, PDO, Symfony/Doctrine, Laravel/Eloquent.</p>
<h2>Noncompliant Code Example</h2>
<pre>
function authenticate() {
  if( isset( $_POST[ 'Connect' ] ) ) {
    $login = $_POST[ 'login' ];
    $pass = $_POST[ 'pass' ];

    $query = "SELECT * FROM users WHERE login = '" . $login . "' AND pass = '" . $pass . "'"; // Unsafe

    // If the special value "foo' OR 1=1 --" is passed as either the user or pass, authentication is bypassed
    // Indeed, if it is passed as a user, the query becomes:
    // SELECT * FROM users WHERE user = 'foo' OR 1=1 --' AND pass = '...'
    // As '--' is the comment till end of line syntax in SQL, this is equivalent to:
    // SELECT * FROM users WHERE user = 'foo' OR 1=1
    // which is equivalent to:
    // SELECT * FROM users WHERE 1=1
    // which is equivalent to:
    // SELECT * FROM users

    $con = getDatabaseConnection();
    $result = mysqli_query($con, $query);

    $authenticated = false;
    if ( $row = mysqli_fetch_row( $result ) ) {
      $authenticated = true;
    }
    mysqli_free_result( $result );
    return $authenticated;
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
function authenticate() {
  if( isset( $_POST[ 'Connect' ] ) ) {
    $login = $_POST[ 'login' ];
    $pass = $_POST[ 'pass' ];

    $query = "SELECT * FROM users WHERE login = ? AND pass = ?"; // Safe even if authenticate() method is still vulnerable to brute-force attack in this specific case

    $stmt = $pdo-&gt;prepare($query);

    $stmt-&gt;execute(array($login, $pass));

    $authenticated = false;
    if ( $stmt-&gt;rowCount() == 1 ) {
      $authenticated = true;
    }

    return $authenticated;
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/564.html">MITRE, CWE-564</a> - SQL Injection: Hibernate </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/20.html">MITRE, CWE-20</a> - Improper Input Validation </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/943.html">MITRE, CWE-943</a> - Improper Neutralization of Special Elements in Data Query Logic
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/PgIRAg">CERT, IDS00-J.</a> - Prevent SQL injection </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S2083">phpsecurity:S2083</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Constructing file
system paths directly from tainted data could enable an attacker to inject specially crafted values, such as <code>'../'</code>, that change the
initial path and, when accessed, resolve to a path on the filesystem where the user should normally not have access.</p>
<p>A successful attack might give an attacker the ability to read, modify, or delete sensitive information from the file system and sometimes even
execute arbitrary operating system commands. This is often referred to as a "path traversal" or "directory traversal" attack.</p>
<p>The mitigation strategy should be based on the whitelisting of allowed paths or characters.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$userId = $_GET["userId"];
$fileUUID = $_GET["fileUUID"];

if ( $_SESSION["userId"] == $userId ) {
  unlink("/storage/" . $userId . "/" . $fileUUID); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
$userId = (int) $_GET["userId"];
$fileUUID = (int) $_GET["fileUUID"];

if ( $_SESSION["userId"] == $userId ) {
  unlink("/storage/" . $userId . "/" . $fileUUID);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/22">MITRE, CWE-22</a> - Improper Limitation of a Pathname to a Restricted Directory ('Path
  Traversal') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/23">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/36">MITRE, CWE-36</a> - Absolute Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/99">MITRE, CWE-99</a> - Improper Control of Resource Identifiers ('Resource Injection') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S2091">phpsecurity:S2091</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing XPath expressions directly from tainted
data enables attackers to inject specially crafted values that changes the initial meaning of the expression itself. Successful XPath injection
attacks can read sensitive information from XML documents.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$user = $_GET["user"];
$pass = $_GET["pass"];

$doc = new DOMDocument();
$doc-&gt;load("test.xml");
$xpath = new DOMXPath($doc);

$expression = "/users/user[@name='" . $user . "' and @pass='" . $pass . "']";
$xpath-&gt;evaluate($expression); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$user = $_GET["user"];
$pass = $_GET["pass"];

$doc = new DOMDocument();
$doc-&gt;load("test.xml");
$xpath = new DOMXPath($doc);

$user = str_replace("'", "&amp;apos;", $user);
$pass = str_replace("'", "&amp;apos;", $pass);

$expression = "/users/user[@name='" . $user . "' and @pass='" . $pass . "']";
$xpath-&gt;evaluate($expression); // Compliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/643">MITRE, CWE-643</a> - Improper Neutralization of Data within XPath Expressions </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/BwLEAw">CERT, IDS53-J.</a> - Prevent XPath Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=objc:S2486">objc:S2486</a>
					</td>
					<td>
						<details>
							<p>When exceptions occur, it is usually a bad idea to simply ignore them. Instead, it is better to handle them properly, or at least to log them.</p>
<h2>Noncompliant Code Example</h2>
<pre>
void save() {
  try {
    saveDocument();
  } catch (const std::exception&amp; ex) {
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
void save() {
  try {
    saveDocument();
  } catch (const std::exception&amp; ex) {
    log &lt;&lt; "Exception while saving the document: " &lt;&lt; ex.what();
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring">OWASP Top 10 2017 Category A10</a> - Insufficient
  Logging &amp; Monitoring </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/391.html">MITRE, CWE-391</a> - Unchecked Error Condition </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=objc:S1081">objc:S1081</a>
					</td>
					<td>
						<details>
							<p>When using legacy C functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer
overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be
executed.</p>
<p>This rule reports use of the following insecure functions: <code>strcpy()</code>, <code>strcat()</code>, <code>sprintf()</code>,
<code>gets()</code> and <code>getpw()</code>.</p>
<p>In such cases, it's better to use an alternate, secure function which allows you to define the maximum number of characters to be written to the
buffer:</p>
<ul>
  <li> <code>strlcpy</code> (BSD library) or <code>strncpy</code> </li>
  <li> <code>strlcat</code> (BSD library) or <code>strncat</code> </li>
  <li> <code>snprintf</code> </li>
  <li> <code>fgets</code> </li>
  <li> <code>getpwuid</code> </li>
</ul>
<p>(Be aware that <code>strncpy</code> and <code>strncat</code> don't guarantee the string will be null-terminated.)</p>
<h2>Noncompliant Code Example</h2>
<pre>
sprintf(str, "%s", message);   // Noncompliant
strcpy(str, message); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
snprintf(str, sizeof(str), "%s", message);
strlcpy(str, message, sizeof(str));

strncpy(str, message, sizeof(str) -1); // Leave room for null
str[sizeof(str) - 1] = '\0'; // Make sure the string is null-terminated
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QwY">CERT, STR07-C.</a> - Use the bounds-checking interfaces for string manipulation
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2068">php:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$uname = "steve";
$password = "blue";
connect($uname, $password);
</pre>
<h2>Compliant Solution</h2>
<pre>
$uname = getEncryptedUser();
$password = getEncryptedPass();
connect($uname, $password);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2278">php:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
&lt;?php
  $ciphertext = mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_DES_COMPAT, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_TRIPLEDES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_3DES, $key, $plaintext, $mode); // Noncompliant

  $cipher = "des-ede3-cfb";  // Noncompliant
  $ciphertext_raw = openssl_encrypt($plaintext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
?&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
&lt;?php
  $ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $plaintext, MCRYPT_MODE_CBC, $iv);
?&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S4433">php:S4433</a>
					</td>
					<td>
						<details>
							<p>An un-authenticated LDAP connection can lead to transactions without access control. Authentication, and with it, access control, are the last line
of defense against LDAP injections and should not be disabled.</p>
<p>This rule raises an issue when an anonymous LDAP connection is created.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn); // Noncompliant; anonymous authentication, no user/password provided
}
</pre>
<h2>Compliant Solution</h2>
<pre>
$ldaprdn  = 'uname';
$ldappass = 'password';

$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass); // Compliant
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/521.html">CWE-521</a> - Weak Password Requirements </li>
  <li> <a href="https://docs.oracle.com/javase/tutorial/jndi/ldap/authentication.html">Modes of Authenticating to LDAP</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ANONYMOUS">LDAP_ANONYMOUS</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=c:S1081">c:S1081</a>
					</td>
					<td>
						<details>
							<p>When using legacy C functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer
overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be
executed.</p>
<p>This rule reports use of the following insecure functions: <code>strcpy()</code>, <code>strcat()</code>, <code>sprintf()</code>,
<code>gets()</code> and <code>getpw()</code>.</p>
<p>In such cases, it's better to use an alternate, secure function which allows you to define the maximum number of characters to be written to the
buffer:</p>
<ul>
  <li> <code>strlcpy</code> (BSD library) or <code>strncpy</code> </li>
  <li> <code>strlcat</code> (BSD library) or <code>strncat</code> </li>
  <li> <code>snprintf</code> </li>
  <li> <code>fgets</code> </li>
  <li> <code>getpwuid</code> </li>
</ul>
<p>(Be aware that <code>strncpy</code> and <code>strncat</code> don't guarantee the string will be null-terminated.)</p>
<h2>Noncompliant Code Example</h2>
<pre>
sprintf(str, "%s", message);   // Noncompliant
strcpy(str, message); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
snprintf(str, sizeof(str), "%s", message);
strlcpy(str, message, sizeof(str));

strncpy(str, message, sizeof(str) -1); // Leave room for null
str[sizeof(str) - 1] = '\0'; // Make sure the string is null-terminated
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QwY">CERT, STR07-C.</a> - Use the bounds-checking interfaces for string manipulation
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=vbnet:S2068">vbnet:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Dim username As String = "admin"
Dim password As String = "Password123"
Dim usernamePassword As String = "user=admin&amp;password=Password123"
Dim usernamePassword2 As String = "user=admin&amp;" &amp; "password=" &amp; password
</pre>
<h2>Compliant Solution</h2>
<pre>
Dim username As String = "admin"
Dim password As String = GetEncryptedPassword()
Dim usernamePassword As String = String.Format("user={0}&amp;password={1}", GetEncryptedUsername(), GetEncryptedPassword())
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1951">flex:S1951</a>
					</td>
					<td>
						<details>
							<p>The <code>trace()</code> function outputs debug statements, which can be read by anyone with a debug version of the Flash player. Because sensitive
information could easily be exposed in this manner, <code>trace()</code> should never appear in production code.</p>
<h2>Noncompliant Code Example</h2>
<pre>
    var val:Number = doCalculation();
    trace("Calculation result: " + val);  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
    var val:Number = doCalculation();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1444">flex:S1444</a>
					</td>
					<td>
						<details>
							<p>There is no good reason to declare a field "public" and "static" without also declaring it "const". Most of the time this is a kludge to share a
state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to
<code>null</code>. </p>
<h2>Noncompliant Code Example</h2>
<pre>
public class Greeter {
  public static var foo:Foo = new Foo(...);
  ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class Greeter {
  public static const FOO:Foo = new Foo(...);
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/500.html">MITRE, CWE-500</a> - Public Static Field Not Marked Final </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QQBqAQ">CERT OBJ10-J.</a> - Do not use public static nonfinal fields </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1442">flex:S1442</a>
					</td>
					<td>
						<details>
							<p><code>Alert.show(...)</code> can be useful for debugging during development, but in production mode this kind of pop-up could expose sensitive
information to attackers, and should never be displayed. </p>
<h2>Noncompliant Code Example</h2>
<pre>
if(unexpectedCondition)
{
  Alert.show("Unexpected Condition");
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cpp:S2486">cpp:S2486</a>
					</td>
					<td>
						<details>
							<p>When exceptions occur, it is usually a bad idea to simply ignore them. Instead, it is better to handle them properly, or at least to log them.</p>
<h2>Noncompliant Code Example</h2>
<pre>
void save() {
  try {
    saveDocument();
  } catch (const std::exception&amp; ex) {
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
void save() {
  try {
    saveDocument();
  } catch (const std::exception&amp; ex) {
    log &lt;&lt; "Exception while saving the document: " &lt;&lt; ex.what();
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring">OWASP Top 10 2017 Category A10</a> - Insufficient
  Logging &amp; Monitoring </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/391.html">MITRE, CWE-391</a> - Unchecked Error Condition </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cpp:S1081">cpp:S1081</a>
					</td>
					<td>
						<details>
							<p>When using legacy C functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer
overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be
executed.</p>
<p>This rule reports use of the following insecure functions: <code>strcpy()</code>, <code>strcat()</code>, <code>sprintf()</code>,
<code>gets()</code> and <code>getpw()</code>.</p>
<p>In such cases, it's better to use an alternate, secure function which allows you to define the maximum number of characters to be written to the
buffer:</p>
<ul>
  <li> <code>strlcpy</code> (BSD library) or <code>strncpy</code> </li>
  <li> <code>strlcat</code> (BSD library) or <code>strncat</code> </li>
  <li> <code>snprintf</code> </li>
  <li> <code>fgets</code> </li>
  <li> <code>getpwuid</code> </li>
</ul>
<p>(Be aware that <code>strncpy</code> and <code>strncat</code> don't guarantee the string will be null-terminated.)</p>
<h2>Noncompliant Code Example</h2>
<pre>
sprintf(str, "%s", message);   // Noncompliant
strcpy(str, message); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
snprintf(str, sizeof(str), "%s", message);
strlcpy(str, message, sizeof(str));

strncpy(str, message, sizeof(str) -1); // Leave room for null
str[sizeof(str) - 1] = '\0'; // Make sure the string is null-terminated
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QwY">CERT, STR07-C.</a> - Use the bounds-checking interfaces for string manipulation
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2228">csharpsquid:S2228</a>
					</td>
					<td>
						<details>
							<p>Debug statements are always useful during development. But include them in production code - particularly in code that runs client-side - and you
run the risk of inadvertently exposing sensitive information.</p>
<h2>Noncompliant Code Example</h2>
<pre>
private void DoSomething()
{
    // ...
    Console.WriteLine("so far, so good..."); // Noncompliant
    // ...
}
</pre>
<h2>Exceptions</h2>
<p>The following are ignored by this rule:</p>
<ul>
  <li> Console Applications </li>
  <li> Calls in methods decorated with <code>[Conditional ("DEBUG")]</code> </li>
  <li> Calls included in DEBUG preprocessor branches (<code>#if DEBUG</code>) </li>
</ul>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2386">csharpsquid:S2386</a>
					</td>
					<td>
						<details>
							<p><code>public static</code> mutable fields of classes which are accessed directly should be protected to the degree possible. This can be done by
reducing the accessibility of the field or by changing the return type to an immutable type.</p>
<p>This rule raises issues for <code>public static</code> fields with a type inheriting/implementing <code>System.Array</code> or
<code>System.Collections.Generic.ICollection&lt;T&gt;</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class A
{
  public static string[] strings1 = {"first","second"};  // Noncompliant
  public static List&lt;String&gt; strings3 = new List&lt;String&gt;();  // Noncompliant
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class A
{
  protected static string[] strings1 = {"first","second"};
  protected static List&lt;String&gt; strings3 = new List&lt;String&gt;();
  // ...
}
</pre>
<h2>Exceptions</h2>
<p>No issue is reported:</p>
<ul>
  <li> If the type of the field inherits/implements one (at least) of the following types:
    <ul>
      <li> <code>System.Collections.ObjectModel.ReadOnlyCollection&lt;T&gt;</code> </li>
      <li> <code>System.Collections.ObjectModel.ReadOnlyDictionary&lt;TKey, TValue&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableArray&lt;T&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableDictionary&lt;TKey, TValue&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableList&lt;T&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableSet&lt;T&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableStack&lt;T&gt;</code> </li>
      <li> <code>System.Collections.Immutable.IImmutableQueue&lt;T&gt;</code> </li>
    </ul> </li>
  <li> If the field is <code>readonly</code> and is initialized inline with an immutable type (i.e. inherits/implements one of the types in the
  previous list) or null. </li>
</ul>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/582.html">MITRE, CWE-582</a> - Array Declared Public, Final, and Static </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/607.html">MITRE, CWE-607</a> - Public Static Final Field References Mutable Object </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/rwBc">CERT, OBJ01-J.</a> - Limit accessibility of fields </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/JQLEAw">CERT, OBJ13-J.</a> - Ensure that references to mutable objects are not exposed
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4564">csharpsquid:S4564</a>
					</td>
					<td>
						<details>
							<p>ASP.Net has a feature to validate HTTP requests to prevent potentially dangerous content to perform a cross-site scripting (XSS) attack. There is
no reason to disable this mechanism even if other checks to prevent XXS attacks are in place.</p>
<p>This rule raises an issue if a method with parameters is marked with <code>System.Web.Mvc.HttpPostAttribute</code> and not
<code>System.Web.Mvc.ValidateInputAttribute(true)</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class FooBarController : Controller
{
    [HttpPost] // Noncompliant
    [ValidateInput(false)]
    public ActionResult Purchase(string input)
    {
        return Foo(input);
    }

    [HttpPost] // Noncompliant
    public ActionResult PurchaseSomethingElse(string input)
    {
        return Foo(input);
    }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class FooBarController : Controller
{
    [HttpPost]
    [ValidateInput(true)] // Compliant
    public ActionResult Purchase(string input)
    {
        return Foo(input);
    }
}
</pre>
<h2>Exceptions</h2>
<p>Parameterless methods marked with <code>System.Web.Mvc.HttpPostAttribute</code> will not trigger this issue.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/79">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation ('Cross-site
  Scripting') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> <a href="https://www.owasp.org/index.php/ASP.NET_Request_Validation">OWASP ASP.NET Request Validation</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2278">csharpsquid:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
using (var tripleDES = new TripleDESCryptoServiceProvider()) //Noncompliant
{
  //...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
using (var aes = new AesCryptoServiceProvider())
{
  //...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4211">csharpsquid:S4211</a>
					</td>
					<td>
						<details>
							<p>Transparency attributes, <code>SecurityCriticalAttribute</code> and <code>SecuritySafeCriticalAttribute</code> are used to identify code that
performs security-critical operations. The second one indicates that it is safe to call this code from transparent, while the first one does not.
Since the transparency attributes of code elements with larger scope take precedence over transparency attributes of code elements that are contained
in the first element a class, for instance, with a <code>SecurityCriticalAttribute</code> can not contain a method with a
<code>SecuritySafeCriticalAttribute</code>.</p>
<p>This rule raises an issue when a member is marked with a <code>System.Security</code> security attribute that has a different transparency than the
security attribute of a container of the member.</p>
<h2>Noncompliant Code Example</h2>
<pre>
using System;
using System.Security;

namespace MyLibrary
{

    [SecurityCritical]
    public class Foo
    {
        [SecuritySafeCritical] // Noncompliant
        public void Bar()
        {
        }
    }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
using System;
using System.Security;

namespace MyLibrary
{

    [SecurityCritical]
    public class Foo
    {
        public void Bar()
        {
        }
    }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4212">csharpsquid:S4212</a>
					</td>
					<td>
						<details>
							<p>Because serialization constructors allocate and initialize objects, security checks that are present on regular constructors must also be present
on a serialization constructor. Failure to do so would allow callers that could not otherwise create an instance to use the serialization constructor
to do this.</p>
<p>This rule raises an issue when a type implements the <code>System.Runtime.Serialization.ISerializable</code> interface, is not a delegate or
interface, is declared in an assembly that allows partially trusted callers and has a constructor that takes a
<code>System.Runtime.Serialization.SerializationInfo</code> object and a <code>System.Runtime.Serialization.StreamingContext</code> object which is
not secured by a security check, but one or more of the regular constructors in the type is secured.</p>
<h2>Noncompliant Code Example</h2>
<pre>
using System;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Security;
using System.Security.Permissions;

[assembly: AllowPartiallyTrustedCallersAttribute()]
namespace MyLibrary
{
    [Serializable]
    public class Foo : ISerializable
    {
        private int n;

        [FileIOPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
        public Foo()
        {
           n = -1;
        }

        protected Foo(SerializationInfo info, StreamingContext context) // Noncompliant
        {
           n = (int)info.GetValue("n", typeof(int));
        }

        void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
        {
           info.AddValue("n", n);
        }
    }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
using System;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Security;
using System.Security.Permissions;

[assembly: AllowPartiallyTrustedCallersAttribute()]
namespace MyLibrary
{
    [Serializable]
    public class Foo : ISerializable
    {
        private int n;

        [FileIOPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
        public Foo()
        {
           n = -1;
        }

        [FileIOPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
        protected Foo(SerializationInfo info, StreamingContext context)
        {
           n = (int)info.GetValue("n", typeof(int));
        }

        void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
        {
           info.AddValue("n", n);
        }
    }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization">OWASP Top 10 2017 Category A8</a> - Insecure Deserialization
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2486">csharpsquid:S2486</a>
					</td>
					<td>
						<details>
							<p>When exceptions occur, it is usually a bad idea to simply ignore them. Instead, it is better to handle them properly, or at least to log them.</p>
<p>This rule only reports on empty catch clauses that catch generic <code>Exception</code>s.</p>
<h2>Noncompliant Code Example</h2>
<pre>
string text = "";
try
{
    text = File.ReadAllText(fileName);
}
catch (Exception exc) // Noncompliant
{
}
</pre>
<h2>Compliant Solution</h2>
<pre>
string text = "";
try
{
    text = File.ReadAllText(fileName);
}
catch (Exception exc)
{
    logger.Log(exc);
}
</pre>
<h2>Exceptions</h2>
<p>When a block contains a comment, it is not considered to be empty.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring">OWASP Top 10 2017 Category A10</a> - Insufficient
  Logging &amp; Monitoring </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/391.html">MITRE, CWE-391</a> - Unchecked Error Condition </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4433">csharpsquid:S4433</a>
					</td>
					<td>
						<details>
							<p>An un-authenticated LDAP connection can lead to transactions without access control. Authentication, and with it, access control, are the last line
of defense against LDAP injections and should not be disabled.</p>
<p>This rule raises an issue when an LDAP connection is created with <code>AuthenticationTypes.Anonymous</code> or
<code>AuthenticationTypes.None</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DirectoryEntry myDirectoryEntry = new DirectoryEntry(adPath);
myDirectoryEntry.AuthenticationType = AuthenticationTypes.None; // Noncompliant

DirectoryEntry myDirectoryEntry = new DirectoryEntry(adPath, "u", "p", AuthenticationTypes.None); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
DirectoryEntry myDirectoryEntry = new DirectoryEntry(myADSPath); // Compliant; default DirectoryEntry.AuthenticationType property value is "Secure" since .NET Framework 2.0

DirectoryEntry myDirectoryEntry = new DirectoryEntry(myADSPath, "u", "p", AuthenticationTypes.Secure);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/521.html">CWE-521</a> - Weak Password Requirements </li>
  <li> <a href="https://docs.oracle.com/javase/tutorial/jndi/ldap/authentication.html">Modes of Authenticating to LDAP</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ANONYMOUS">LDAP_ANONYMOUS</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4432">csharpsquid:S4432</a>
					</td>
					<td>
						<details>
							<p>Encryption algorithms can be used with various modes. Some combinations are not secured:</p>
<ul>
  <li> Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does
  not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic
  protocols at all. </li>
  <li> Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks. CBC + PKCS#7 can be used if combined with
  an authenticity check (HMAC-SHA256 for example) on the cipher text. </li>
</ul>
<p>In both cases, Galois/Counter Mode (GCM) with no padding should be preferred. As the .NET framework doesn't provide this natively, the use of a
certified third party lib is recommended. </p>
<p>This rule raises an issue when any of the following CipherMode is detected: ECB, CBC, OFB, CFB, CTS.</p>
<h2>Noncompliant Code Example</h2>
<pre>
AesManaged aes = new AesManaged
{
  KeySize = 128,
  BlockSize = 128,
  Mode = CipherMode.OFB, // Noncompliant
  Padding = PaddingMode.PKCS7
};
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf">Recommendation for Block Cipher Modes of Operation</a>
  </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#ECB_MODE">ECB_MODE</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#PADDING_ORACLE">PADDING_ORACLE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2068">csharpsquid:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
string username = "admin";
string password = "Password123"; // Noncompliant
string usernamePassword  = "user=admin&amp;password=Password123"; // Noncompliant
string usernamePassword2 = "user=admin&amp;" + "password=" + password; // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
string username = "admin";
string password = GetEncryptedPassword();
string usernamePassword = string.Format("user={0}&amp;password={1}", GetEncryptedUsername(), GetEncryptedPassword());
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S3884">csharpsquid:S3884</a>
					</td>
					<td>
						<details>
							<p><code>CoSetProxyBlanket</code> and <code>CoInitializeSecurity</code> both work to set the permissions context in which the process invoked
immediately after is executed. Calling them from within that process is useless because it's too late at that point; the permissions context has
already been set.</p>
<p>Specifically, these methods are meant to be called from non-managed code such as a C++ wrapper that then invokes the managed, i.e. C# or VB.NET,
code.</p>
<h2>Noncompliant Code Example</h2>
<pre>
[DllImport("ole32.dll")]
static extern int CoSetProxyBlanket([MarshalAs(UnmanagedType.IUnknown)]object pProxy, uint dwAuthnSvc, uint dwAuthzSvc,
	[MarshalAs(UnmanagedType.LPWStr)] string pServerPrincName, uint dwAuthnLevel, uint dwImpLevel, IntPtr pAuthInfo,
	uint dwCapabilities);

public enum RpcAuthnLevel
{
	Default = 0,
	None = 1,
	Connect = 2,
	Call = 3,
	Pkt = 4,
	PktIntegrity = 5,
	PktPrivacy = 6
}

public enum RpcImpLevel
{
	Default = 0,
	Anonymous = 1,
	Identify = 2,
	Impersonate = 3,
	Delegate = 4
}

public enum EoAuthnCap
{
	None = 0x00,
	MutualAuth = 0x01,
	StaticCloaking = 0x20,
	DynamicCloaking = 0x40,
	AnyAuthority = 0x80,
	MakeFullSIC = 0x100,
	Default = 0x800,
	SecureRefs = 0x02,
	AccessControl = 0x04,
	AppID = 0x08,
	Dynamic = 0x10,
	RequireFullSIC = 0x200,
	AutoImpersonate = 0x400,
	NoCustomMarshal = 0x2000,
	DisableAAA = 0x1000
}

[DllImport("ole32.dll")]
public static extern int CoInitializeSecurity(IntPtr pVoid, int cAuthSvc, IntPtr asAuthSvc, IntPtr pReserved1,
	RpcAuthnLevel level, RpcImpLevel impers, IntPtr pAuthList, EoAuthnCap dwCapabilities, IntPtr pReserved3);

static void Main(string[] args)
{
	var hres1 = CoSetProxyBlanket(null, 0, 0, null, 0, 0, IntPtr.Zero, 0); // Noncompliant

	var hres2 = CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, RpcAuthnLevel.None,
		RpcImpLevel.Impersonate, IntPtr.Zero, EoAuthnCap.None, IntPtr.Zero); // Noncompliant
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:DebuggerStatement">javascript:DebuggerStatement</a>
					</td>
					<td>
						<details>
							<p>The debugger statement can be placed anywhere in procedures to suspend execution. Using the debugger statement is similar to setting a breakpoint
in the code. By definition such statement must absolutely be removed from the source code to prevent any unexpected behavior or added vulnerability to
attacks in production.</p>
<h2>Noncompliant Code Example</h2>
<pre>
for (i = 1; i&lt;5; i++) {
  // Print i to the Output window.
  Debug.write("loop index is " + i);
  // Wait for user to resume.
  debugger;
}
</pre>
<h2>Compliant Solution</h2>
<pre>
for (i = 1; i&lt;5; i++) {
  // Print i to the Output window.
  Debug.write("loop index is " + i);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:S2819">javascript:S2819</a>
					</td>
					<td>
						<details>
							<p>HTML5 adds the ability to send messages to documents served from other domains. According to the specification:</p>
<blockquote>
  Authors should not use the wildcard keyword (
  <code>*</code>) in the
  <code>targetOrigin</code> argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message
  is only delivered to the recipient to which it was intended.
</blockquote>
<p>To mitigate the risk of sending sensitive information to a document served from a hostile or unknown domain, this rule raises an issue each time
<code>Window.postMessage</code> is used.</p>
<h2>Noncompliant Code Example</h2>
<pre>
var myWindow = document.getElementById('myIFrame').contentWindow;
myWindow.postMessage(message, "*"); // Noncompliant; how do you know what you loaded in 'myIFrame' is still there?
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:S2817">javascript:S2817</a>
					</td>
					<td>
						<details>
							<p>The Web SQL Database standard never saw the light of day. It was first formulated, then deprecated by the W3C and was only implemented in some
browsers. (It is not supported in Firefox or IE.)</p>
<p>Further, the use of a Web SQL Database poses security concerns, since you only need its name to access such a database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
var db = window.openDatabase("myDb", "1.0", "Personal secrets stored here", 2*1024*1024);  // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:S3271">javascript:S3271</a>
					</td>
					<td>
						<details>
							<p>Session storage and local storage are HTML 5 features which allow developers to easily store megabytes of data client-side, as opposed to the 4Kb
cookies can accommodate. While useful to speed applications up on the client side, it can be dangerous to store sensitive information this way because
the data is not encrypted by default and any script on the page may access it.</p>
<p>This rule raises an issue when the <code>localStorage</code> and <code>sessionStorage</code> API's are used.</p>
<h2>Noncompliant Code Example</h2>
<pre>
localStorage.setItem("login", login); // Noncompliant
sessionStorage.setItem("sessionId", sessionId); // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://dl.packetstormsecurity.net/papers/attack/HTML5AttackVectors_RafayBaloch_UPDATED.pdf">Packet Storm Security</a> - HTML 5 Modern
  Day Attack And Defence Vectors </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:S2611">javascript:S2611</a>
					</td>
					<td>
						<details>
							<p>Including content in your site from an untrusted source can expose your users to attackers and even compromise your own site. For that reason, this
rule raises an issue for each non-relative URL.</p>
<h2>Noncompliant Code Example</h2>
<pre>
function include(url) {
  var s = document.createElement("script");
  s.setAttribute("type", "text/javascript");
  s.setAttribute("src", url);
  document.body.appendChild(s);
}
include("http://hackers.com/steal.js")  // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/829">MITRE, CWE-829</a> - Inclusion of Functionality from Untrusted Control Sphere </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javascript:S1442">javascript:S1442</a>
					</td>
					<td>
						<details>
							<p><code>alert(...)</code> as well as <code>confirm(...)</code> and <code>prompt(...)</code> can be useful for debugging during development, but in
production mode this kind of pop-up could expose sensitive information to attackers, and should never be displayed. </p>
<h2>Noncompliant Code Example</h2>
<pre>
if(unexpectedCondition) {
  alert("Unexpected Condition");
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S2068">abap:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>Noncompliant Code Example</h2>
<pre>
DATA: password(10) VALUE 'secret123',
           pwd(10) VALUE 'secret123'.
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S1493">abap:S1493</a>
					</td>
					<td>
						<details>
							<p>There are two main reasons to ban dynamic clauses in <code>SELECT</code> statements. </p>
<p>The first relates to maintainability. One of the nice features of ABAP Design Time is the connection to the data dictionary; you get syntax errors
if you try to address table fields that are not present anymore or that have typos. With dynamic SQL, the ability to statically check the code for
this type of error is lost. </p>
<p>The other more critical reason relates to security. By definition, dynamic clauses make an application susceptible to SQL injection attacks.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SELECT (select_clause)
 FROM (from_clause) CLIENT SPECIFIED INTO &lt;fs&gt;
 WHERE (where_clause)
 GROUP BY (groupby_clause) HAVING (having_clause)
 ORDER BY (orderby_clause).
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/89.html">MITRE, CWE-89</a> - SQL Injection </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S5117">abap:S5117</a>
					</td>
					<td>
						<details>
							<p>Every <code>AUTHORITY-CHECK</code> statement sets the fields <code>SY-SUBRC</code> (also accessible as <code>SYST-SUBRC</code>) to the
authorization check result. Thus <code>SY-SUBRC</code> value should be checked just after every <code>AUTHORITY-CHECK</code> statement.</p>
<h2>Noncompliant Code Example</h2>
<pre>
AUTHORITY-CHECK OBJECT 'S_MYOBJ' "Noncompliant
    ID 'ID1' FIELD myvalue.
</pre>
<h2>Compliant Solution</h2>
<pre>
AUTHORITY-CHECK OBJECT 'S_MYOBJ'  "Compliant
    ID 'ID1' FIELD myvalue.

  IF sy-subrc &lt;&gt; 0.
    MESSAGE 'NOT AUTHORIZED' TYPE 'E'.
  ENDIF.
</pre>
<h2>Exceptions</h2>
<p>No issue will be raised in the following cases:</p>
<ul>
  <li> One or more <code>WRITE</code> operation are performed between the <code>AUTHORITY-CHECK</code> statement and <code>SY-SUBRC</code> check. An
  exception will be however raised if the <code>WRITE</code> operation is a <code>WRITE ... TO</code> statement, as this will set again
  <code>SY-SUBRC</code>. </li>
  <li> <code>SY-SUBRC</code>'s value is assigned to a variable. We then assume that it will be checked later. </li>
</ul>
<pre>
AUTHORITY-CHECK OBJECT 'S_MYOBJ'  "Compliant
    ID 'ID1' FIELD myvalue.
WRITE 'Test' " WRITE is accepted before checking SY-SUBRC
IF SY-SUBRC &lt;&gt; 0.
    EXIT.
ENDIF.

AUTHORITY-CHECK OBJECT 'S_MYOBJ'  "Compliant
    ID 'ID1' FIELD myvalue.
Tmp = SY-SUBRC " Assigning SY-SUBRC value to a variable. We assume that it will be checked later.
IF Tmp &lt;&gt; 0.
    EXIT.
ENDIF.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S5115">abap:S5115</a>
					</td>
					<td>
						<details>
							<p>Checking logged users' permissions by comparing their name to a hardcoded string can create security vulnerabilities. It prevents system
administrators from changing users' permissions when needed (example: when their account has been compromised). Thus system fields
<code>SY-UNAME</code> and <code>SYST-UNAME</code> should not be compared to hardcoded strings. Use instead <code>AUTHORITY-CHECK</code> to check
users' permissions.</p>
<p>This rule raises an issue when either of the system fields <code>SY-UNAME</code> or <code>SYST-UNAME</code> are compared to a hardcoded value in a
<code>CASE</code> statement or using one of the following operators: <code>=</code>, <code>EQ</code>, <code>&lt;&gt;</code>, <code>NE</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
IF SY-UNAME = 'ALICE'. " Noncompliant
ENDIF.

CASE SY-UNAME.
WHEN 'A'. " Noncompliant
ENDCASE.
</pre>
<h2>Compliant Solution</h2>
<pre>
AUTHORITY-CHECK OBJECT 'S_CARRID'
  ID 'CARRID' FIELD mycarrid.
IF sy-subrc &lt;&gt; 0.
  MESSAGE 'Not authorized' TYPE 'E'.
ENDIF.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S1486">abap:S1486</a>
					</td>
					<td>
						<details>
							<p>A <code>BREAK-POINT</code> statement is used when debugging an application with help of the ABAP Debugger. But such debugging statements could make
an application vulnerable to attackers, and should not be left in the source code.</p>
<h2>Noncompliant Code Example</h2>
<pre>
IF wv_parallel EQ 'X'.
  BREAK-POINT.
  WAIT UNTIL g_nb_return EQ wv_nb_call.
ENDIF.
</pre>
<h2>Compliant Solution</h2>
<pre>
IF wv_parallel EQ 'X'.
  WAIT UNTIL g_nb_return EQ wv_nb_call.
ENDIF.
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2115">squid:S2115</a>
					</td>
					<td>
						<details>
							<p>Failure to password-protect a database is so careless or naive as to be almost negligent. Databases should always be password protected, but the
use of a database connection with an empty password is a clear indication of a database that is not protected.</p>
<p>This rule flags database connections with empty passwords.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Connection conn = DriverManager.getConnection("jdbc:derby:memory:myDB;create=true", "AppLogin", "");
Connection conn2 = DriverManager.getConnection("jdbc:derby:memory:myDB;create=true?user=user&amp;password=");
</pre>
<h2>Compliant Solution</h2>
<pre>
DriverManager.getConnection("jdbc:derby:memory:myDB;create=true?user=user&amp;password=password");

DriverManager.getConnection("jdbc:mysql://address=(host=myhost1)(port=1111)(key1=value1)(user=sandy)(password=secret),address=(host=myhost2)(port=2222)(key2=value2)(user=sandy)(password=secret)/db");

DriverManager.getConnection("jdbc:mysql://sandy:secret@[myhost1:1111,myhost2:2222]/db");

String url = "jdbc:postgresql://localhost/test";
Properties props = new Properties();
props.setProperty("user", "fred");
props.setProperty("password", "secret");
DriverManager.getConnection(url, props);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/521.html">MITRE, CWE-521</a> - Weak Password Requirements </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1148">squid:S1148</a>
					</td>
					<td>
						<details>
							<p><code>Throwable.printStackTrace(...)</code> prints a <code>Throwable</code> and its stack trace to some stream. By default that stream
<code>System.Err</code>, which could inadvertently expose sensitive information.</p>
<p>Loggers should be used instead to print <code>Throwable</code>s, as they have many advantages:</p>
<ul>
  <li> Users are able to easily retrieve the logs. </li>
  <li> The format of log messages is uniform and allow users to browse the logs easily. </li>
</ul>
<p>This rule raises an issue when <code>printStackTrace</code> is used without arguments, i.e. when the stack trace is printed to the default
stream.</p>
<h2>Noncompliant Code Example</h2>
<pre>
try {
  /* ... */
} catch(Exception e) {
  e.printStackTrace();        // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
try {
  /* ... */
} catch(Exception e) {
  LOGGER.log("context", e);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3329">squid:S3329</a>
					</td>
					<td>
						<details>
							<p>In encryption, when Cipher Block Chaining (CBC) is used, the Initialization Vector (IV) must be random and unpredictable. Otherwise, the encrypted
value is vulnerable to crypto-analysis attacks such as the "Chosen-Plaintext Attack".</p>
<p>An IV value should be associated to one, and only one encryption cycle, because the IV's purpose is to ensure that the same plaintext encrypted
twice will yield two different ciphertexts.</p>
<p>To that end, IV's should be:</p>
<ul>
  <li> random </li>
  <li> unpredictable </li>
  <li> publishable (IVs are frequently published) </li>
  <li> authenticated, along with the ciphertext, with a Message Authentication Code (MAC) </li>
</ul>
<p>This rule raises an issue when the IV is:</p>
<ul>
  <li> hard-coded </li>
  <li> created using <code>java.util.Random</code> rather than <code>java.security.SecureRandom</code>. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyCbcClass {

  public String applyCBC(String strKey, String plainText) {
    byte[] bytesIV = "7cVgr5cbdCZVw5WY".getBytes("UTF-8");

    /* KEY + IV setting */
    IvParameterSpec iv = new IvParameterSpec(bytesIV);
    SecretKeySpec skeySpec = new SecretKeySpec(strKey.getBytes("UTF-8"), "AES");

    /* Ciphering */
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING");
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv);  // Noncompliant because IV hard coded and cannot vary with each ciphering round
    byte[] encryptedBytes = cipher.doFinal(plainText.getBytes("UTF-8"));
    return DatatypeConverter.printBase64Binary(bytesIV) // IV is typically published
            + ";" + DatatypeConverter.printBase64Binary(encryptedBytes);
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class MyCbcClass {

  SecureRandom random = new SecureRandom();

  public String applyCBC(String strKey, String plainText) {
    byte[] bytesIV = new byte[16];
    random.nextBytes(bytesIV);

    /* KEY + IV setting */
    IvParameterSpec iv = new IvParameterSpec(bytesIV);
    SecretKeySpec skeySpec = new SecretKeySpec(strKey.getBytes("UTF-8"), "AES");

    /* Ciphering */
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING");
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv);
    byte[] encryptedBytes = cipher.doFinal(plainText.getBytes("UTF-8"));
    return DatatypeConverter.printBase64Binary(bytesIV)
            + ";" + DatatypeConverter.printBase64Binary(encryptedBytes);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/330">MITRE, CWE-330</a> - Use of Insufficiently Random Values </li>
  <li> OWASP Top 10 2017 Category A6 - Security Misconfiguration </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#STATIC_IV">STATIC_IV</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4684">squid:S4684</a>
					</td>
					<td>
						<details>
							<p>On one side, Spring MVC automatically bind request parameters to beans declared as arguments of methods annotated with
<code>@RequestMapping</code>. Because of this automatic binding feature, it's possible to feed some unexpected fields on the arguments of the
<code>@RequestMapping</code> annotated methods. </p>
<p>On the other end, persistent objects (<code>@Entity</code> or <code>@Document</code>) are linked to the underlying database and updated
automatically by a persistence framework, such as Hibernate, JPA or Spring Data MongoDB.</p>
<p>These two facts combined together can lead to malicious attack: if a persistent object is used as an argument of a method annotated with
<code>@RequestMapping</code>, it's possible from a specially crafted user input, to change the content of unexpected fields into the database.</p>
<p>For this reason, using <code>@Entity</code> or <code>@Document</code> objects as arguments of methods annotated with <code>@RequestMapping</code>
should be avoided.</p>
<p>In addition to <code>@RequestMapping</code>, this rule also considers the annotations introduced in Spring Framework 4.3: <code>@GetMapping</code>,
<code>@PostMapping</code>, <code>@PutMapping</code>, <code>@DeleteMapping</code>, <code>@PatchMapping</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
import javax.persistence.Entity;

@Entity
public class Wish {
  Long productId;
  Long quantity;
  Client client;
}

@Entity
public class Client {
  String clientId;
  String name;
  String password;
}

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class WishListController {

  @PostMapping(path = "/saveForLater")
  public String saveForLater(Wish wish) {
    session.save(wish);
  }

  @RequestMapping(path = "/saveForLater", method = RequestMethod.POST)
  public String saveForLater(Wish wish) {
    session.save(wish);
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class WishDTO {
  Long productId;
  Long quantity;
  Long clientId;
}

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class PurchaseOrderController {

  @PostMapping(path = "/saveForLater")
  public String saveForLater(WishDTO wish) {
    Wish persistentWish = new Wish();
    // do the mapping between "wish" and "persistentWish"
    [...]
    session.save(persistentWish);
  }

  @RequestMapping(path = "/saveForLater", method = RequestMethod.POST)
  public String saveForLater(WishDTO wish) {
    Wish persistentWish = new Wish();
    // do the mapping between "wish" and "persistentWish"
    [...]
    session.save(persistentWish);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/915.html">MITRE, CWE-915</a> - Improperly Controlled Modification of Dynamically-Determined
  Object Attributes </li>
  <li> <a href="https://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf">Two Security Vulnerabilities in the Spring
  Framework’s MVC by Ryan Berg and Dinis Cruz</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3355">squid:S3355</a>
					</td>
					<td>
						<details>
							<p>Every filter defined in <code>web.xml</code> file should be used in a <code>&lt;filter-mapping&gt;</code> element. Otherwise such filters are not
invoked.</p>
<h2>Noncompliant Code Example</h2>
<pre>
  &lt;filter&gt;
     &lt;filter-name&gt;DefinedNotUsed&lt;/filter-name&gt;
     &lt;filter-class&gt;com.myco.servlet.ValidationFilter&lt;/filter-class&gt;
  &lt;/filter&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
  &lt;filter&gt;
     &lt;filter-name&gt;ValidationFilter&lt;/filter-name&gt;
     &lt;filter-class&gt;com.myco.servlet.ValidationFilter&lt;/filter-class&gt;
  &lt;/filter&gt;

  &lt;filter-mapping&gt;
     &lt;filter-name&gt;ValidationFilter&lt;/filter-name&gt;
     &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
  &lt;/filter-mapping&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2278">squid:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
</pre>
<h2>Compliant Solution</h2>
<pre>
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2277">squid:S2277</a>
					</td>
					<td>
						<details>
							<p>Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an
issue as soon as a literal value starts with <code>RSA/NONE</code>. </p>
<h2>Noncompliant Code Example</h2>
<pre>
Cipher rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");
</pre>
<h2>Compliant Solution</h2>
<pre>
Cipher rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/780.html">MITRE CWE-780</a> - Use of RSA Algorithm without OAEP </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#RSA_NO_PADDING">RSA NoPadding Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4424">squid:S4424</a>
					</td>
					<td>
						<details>
							<p>Empty implementations of the <code>X509TrustManager</code> interface are often created to allow connection to a host that is not signed by a root
certificate authority. Such an implementation will accept any certificate, which leaves the application vulnerable to Man-in-the-middle attacks. The
correct solution is to provide an appropriate trust store.</p>
<p>This rule raises an issue when an implementation of <code>X509TrustManager</code> never throws exception.</p>
<h2>Noncompliant Code Example</h2>
<pre>
class TrustAllManager implements X509TrustManager {

    @Override
    public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {  // Noncompliant, nothing means trust any client
    }

    @Override
    public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { // Noncompliant, this method never throws exception, it means trust any client
        LOG.log(Level.SEVERE, ERROR_MESSAGE);
    }

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/295.html">MITRE, CWE-295</a> - Improper Certificate Validation </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4423">squid:S4423</a>
					</td>
					<td>
						<details>
							<p><code>javax.net.ssl.SSLContext.getInstance</code> returns a SSLContext object that implements the specified secure socket protocol. However, not
all protocols are created equal and some legacy ones like "SSL", have been proven to be insecure.</p>
<p>This rule raises an issue when an <code>SSLContext</code> is created with an insecure protocol (ie: a protocol different from "TLS", "DTLS",
"TLSv1.2", "DTLSv1.2", "TLSv1.3", "DTLSv1.3").</p>
<p>The recommended value is "TLS" or "DTLS" as it will always use the latest version of the protocol. However an issue will be raised if the bytecode
was compiled with JDK7 or an even older version of JDK because they are not alias for TLSv1.2 and DTLSv1.2 but for weaker protocols.</p>
<p>Note that calling <code>SSLContext.getInstance(...)</code> with "TLSv1.2" or "DTLSv1.2" doesn't prevent protocol version negotiation. For example,
if a client connects with "TLSv1.1" and the server used <code>SSLContext.getInstance("TLSv1.2")</code>, the connection will use "TLSv1.1". It is
possible to enable only specific protocol versions by calling <code>setEnabledProtocols</code> on <code>SSLSocket</code>, <code>SSLServerSocket</code>
or <code>SSLEngine</code>. However this should be rarely needed as clients usually ask for the most secure protocol supported.</p>
<h2>Noncompliant Code Example</h2>
<pre>
context = SSLContext.getInstance("SSL"); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
context = SSLContext.getInstance("TLSv1.2");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-327</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-326</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https">Diagnosing TLS, SSL, and HTTPS</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4426">squid:S4426</a>
					</td>
					<td>
						<details>
							<p>When generating cryptographic keys (or key pairs), it is important to use a key length that provides enough entropy against brute-force attacks.
For the <code>Blowfish</code> algorithm the key should be at least 128 bits long, while for the <code>RSA</code> algorithm it should be at least 2048
bits long.</p>
<p>This rule raises an issue when a Blowfish key generator or RSA key-pair generator is initialized with too small a length parameter.</p>
<h2>Noncompliant Code Example</h2>
<pre>
KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
keyGen.init(64); // Noncompliant

KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
keyPairGen.initialize(512); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
keyGen.init(128);

KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
keyPairGen.initialize(2048);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#BLOWFISH_KEY_SIZE">BLOWFISH_KEY_SIZE</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#RSA_KEY_SIZE">RSA_KEY_SIZE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3330">squid:S3330</a>
					</td>
					<td>
						<details>
							<p>The <code>HttpOnly</code> cookie attribute tells the browser to prevent client-side scripts from reading cookies with the attribute, and its use
can go a long way to defending against Cross-Site Scripting (XSS) attacks. Thus, as a precaution, the attribute should be set by default on all
cookies set server-side, such as session id cookies.</p>
<p>When implementing Cross Site Request Forgery (XSRF) protection, a JavaScript-readable session cookie, generally named XSRF-TOKEN, should be created
on the first HTTP GET request. For such a cookie, the <code>HttpOnly</code> attribute should be set to "false".</p>
<p>Setting the attribute can be done either programmatically, or globally via configuration files. </p>
<h2>Noncompliant Code Example</h2>
<pre>
Cookie cookie = new Cookie("myCookieName", value); // Noncompliant; by default cookie.isHttpOnly() is returning false
</pre>
<h2>Compliant Solution</h2>
<pre>
Cookie cookie = new Cookie("myCookieName", value);
cookie.setHttpOnly(true); // Compliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HttpOnly">OWASP HttpOnly</a> </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79</a> - Improper Neutralization of Input During Web Page Generation ('Cross-site
  Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/1004.html">CWE-1004</a> - Sensitive Cookie Without 'HttpOnly' Flag </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#HTTPONLY_COOKIE">HTTPONLY_COOKIE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4435">squid:S4435</a>
					</td>
					<td>
						<details>
							<p>An XML External Entity or XSLT External Entity (XXE) vulnerability can occur when a <code>javax.xml.transform.Transformer</code> is created without
enabling "Secure Processing" or when one is created without disabling external DTDs. If that external entity is hijacked by an attacker it may lead to
the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the
parser is located, and other system impacts.</p>
<p>This rule raises an issue when a <code>Transformer</code> is created without either of these settings.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.transform(input, result);
</pre>
<h2>Compliant Solution</h2>
<pre>
TransformerFactory factory = TransformerFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

Transformer transformer = factory.newTransformer();

transformer.transform(input, result);
</pre>
<p>or</p>
<pre>
TransformerFactory factory = TransformerFactory.newInstance();
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");

Transformer transformer = factory.newTransformer();

transformer.transform(input, result);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE)">OWASP Top 10 2017 Category A4</a> - XML External Entities
  (XXE) </li>
  <li> <a href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md">OWASP XXE Cheat
  Sheet</a> </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/611.html">MITRE, CWE-611</a> - Improper Restriction of XML External Entity Reference ('XXE')
  </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_DTD_TRANSFORM_FACTORY">XXE_DTD_TRANSFORM_FACTORY</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_XSLT_TRANSFORM_FACTORY">XXE_XSLT_TRANSFORM_FACTORY</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2258">squid:S2258</a>
					</td>
					<td>
						<details>
							<p>By contract, the <code>NullCipher</code> class provides an "identity cipher" <del></del> one that does not transform or encrypt the plaintext in
any way. As a consequence, the ciphertext is identical to the plaintext. So this class should be used for testing, and never in production code.</p>
<h2>Noncompliant Code Example</h2>
<pre>
NullCipher nc = new NullCipher();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4434">squid:S4434</a>
					</td>
					<td>
						<details>
							<p>JNDI supports the deserialization of objects from LDAP directories, which is fundamentally insecure and can lead to remote code execution.</p>
<p>This rule raises an issue when an LDAP search query is executed with <code>SearchControls</code> configured to allow deserialization.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            true, // Noncompliant; allows deserialization
            deref));
</pre>
<h2>Compliant Solution</h2>
<pre>
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            false,
            deref));
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/502.html">MITRE, CWE-502</a> - Deserialization of Untrusted Data </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization">OWASP Top 10 2017 Category A8</a> - Insecure Deserialization
  </li>
  <li> <a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf">BlackHat
  presentation</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING">LDAP_ENTRY_POISONING</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2254">squid:S2254</a>
					</td>
					<td>
						<details>
							<p>According to the Oracle Java API, the <code>HttpServletRequest.getRequestedSessionId()</code> method:</p>
<blockquote>
  <p>Returns the session ID specified by the client. This may not be the same as the ID of the current valid session for this request. If the client
  did not specify a session ID, this method returns null.</p>
</blockquote>
<p>The session ID it returns is either transmitted in a cookie or a URL parameter so by definition, nothing prevents the end-user from manually
updating the value of this session ID in the HTTP request. </p>
<p>Here is an example of a updated HTTP header:</p>
<pre>
GET /pageSomeWhere HTTP/1.1
Host: webSite.com
User-Agent: Mozilla/5.0
Cookie: JSESSIONID=Hacked_Session_Value'''"&gt;
</pre>
<p>Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (E.G.
Tomcat or Jetty) to see if the value matches the ID of an an existing session. If it does not, the user should be considered unauthenticated.
Moreover, this session ID should never be logged to prevent hijacking of active sessions.</p>
<h2>Noncompliant Code Example</h2>
<pre>
if(isActiveSession(request.getRequestedSessionId()) ){
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/807">MITRE, CWE-807</a> - Reliance on Untrusted Inputs in a Security Decision </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4433">squid:S4433</a>
					</td>
					<td>
						<details>
							<p>An un-authenticated LDAP connection can lead to transactions without access control. Authentication, and with it, access control, are the last line
of defense against LDAP injections and should not be disabled.</p>
<p>This rule raises an issue when an LDAP connection is created with <code>Context.SECURITY_AUTHENTICATION</code> set to <code>"none"</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
// Set up the environment for creating the initial context
Hashtable&lt;String, Object&gt; env = new Hashtable&lt;String, Object&gt;();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");

// Use anonymous authentication
env.put(Context.SECURITY_AUTHENTICATION, "none"); // Noncompliant

// Create the initial context
DirContext ctx = new InitialDirContext(env);
</pre>
<h2>Compliant Solution</h2>
<pre>
// Set up the environment for creating the initial context
Hashtable&lt;String, Object&gt; env = new Hashtable&lt;String, Object&gt;();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");

// Use simple authentication
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=S. User, ou=NewHires, o=JNDITutorial");
env.put(Context.SECURITY_CREDENTIALS, getLDAPPassword());

// Create the initial context
DirContext ctx = new InitialDirContext(env);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/521.html">CWE-521</a> - Weak Password Requirements </li>
  <li> <a href="https://docs.oracle.com/javase/tutorial/jndi/ldap/authentication.html">Modes of Authenticating to LDAP</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#LDAP_ANONYMOUS">LDAP_ANONYMOUS</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4432">squid:S4432</a>
					</td>
					<td>
						<details>
							<p>The Advanced Encryption Standard (AES) encryption algorithm can be used with various modes. Some combinations are not secured:</p>
<ul>
  <li> Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does
  not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic
  protocols at all. </li>
  <li> Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks. </li>
</ul>
<p>In both cases, Galois/Counter Mode (GCM) with no padding should be preferred.</p>
<p>This rule raises an issue when a <code>Cipher</code> instance is created with either ECB or CBC/PKCS5Padding mode.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Cipher c1 = Cipher.getInstance("AES/ECB/NoPadding"); // Noncompliant
Cipher c2 = Cipher.getInstance("AES/CBC/PKCS5Padding"); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf">Recommendation for Block Cipher Modes of Operation</a>
  </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#ECB_MODE">ECB_MODE</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#PADDING_ORACLE">PADDING_ORACLE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2755">squid:S2755</a>
					</td>
					<td>
						<details>
							<p>Allowing external entities in untrusted documents to be processed could lay your systems bare to attackers. Imagine if these entities were
parsed:</p>
<pre>
&lt;!ENTITY xxe SYSTEM "file:///etc/passwd" &gt;]&gt;&lt;foo&gt;&amp;xxe;&lt;/foo&gt;
&lt;!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" &gt;]&gt;&lt;foo&gt;&amp;xxe;&lt;/foo&gt;
</pre>
<p>If you must parse untrusted XML, the best way to protect yourself is to use a local, static DTD during parsing and ignore any DTD's included in
included in the document.</p>
<p>This rule raises an issue when any of the following are used without first disabling external entity processing:
<code>javax.xml.validation.Validator</code>, JAXP's <code>DocumentBuilderFactory</code>, <code>SAXParserFactory</code>, Xerces 1 and Xerces 2 StAX's
<code>XMLInputFactory</code> and <code>XMLReaderFactory</code>.</p>
<p>To disable external entity processing for <code>XMLInputFactory</code>, configure one of the properties
<code>XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES</code> or <code>XMLInputFactory.SUPPORT_DTD</code> to false.</p>
<p>To disable external entity processing for <code>SAXParserFactory</code>, <code>XMLReader</code> or <code>DocumentBuilderFactory</code> configure
one of the features <code>XMLConstants.FEATURE_SECURE_PROCESSING</code> or <code>"http://apache.org/xml/features/disallow-doctype-decl"</code> to
true.</p>
<p>To disable external entity processing for <code>Validator</code>, configure both properties <code>XMLConstants.ACCESS_EXTERNAL_DTD</code>,
<code>XMLConstants.ACCESS_EXTERNAL_SCHEMA</code> to the empty string <code>""</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
/* Load XML stream and display content */
String maliciousSample = "xxe.xml";
XMLInputFactory factory = XMLInputFactory.newInstance();

try (FileInputStream fis = new FileInputStream(malicousSample)) {
  // Load XML stream
  XMLStreamReader xmlStreamReader = factory.createXMLStreamReader(fis);  // Noncompliant; reader is vulnerable

  //...
</pre>
<h2>Compliant Solution</h2>
<pre>
/* Load XML stream and display content */
String maliciousSample = "xxe.xml";
XMLInputFactory factory = XMLInputFactory.newInstance();

// disable external entities
factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, Boolean.FALSE);
factory.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE);

try (FileInputStream fis = new FileInputStream(malicousSample)) {
    // Load XML stream
    XMLStreamReader xmlStreamReader = factory.createXMLStreamReader(fis);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE)">OWASP Top 10 2017 Category A4</a> - XML External Entities
  (XXE) </li>
  <li> <a href="https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet">OWASP XXE Prevention Cheat Sheet</a> </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/611.html">MITRE, CWE-611</a> - Information Exposure Through XML External Entity Reference </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/827.html">MITRE, CWE-827</a> - Improper Control of Document Type Definition </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_XMLSTREAMREADER">XXE_XMLSTREAMREADER</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_SAXPARSER">XXE_SAXPARSER</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_XMLREADER">XXE_XMLREADER</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#XXE_DOCUMENT">XXE_DOCUMENT</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2976">squid:S2976</a>
					</td>
					<td>
						<details>
							<p>Using <code>File.createTempFile</code> as the first step in creating a temporary directory causes a race condition and is inherently unreliable and
insecure. Instead, <code>Files.createTempDirectory</code> (Java 7+) or a library function such as Guava's similarly-named
<code>Files.createTempDir</code> should be used.</p>
<p>This rule raises an issue when the following steps are taken in immediate sequence:</p>
<ul>
  <li> call to <code>File.createTempFile</code> </li>
  <li> delete resulting file </li>
  <li> call <code>mkdir</code> on the File object </li>
</ul>
<p><strong>Note</strong> that this rule is automatically disabled when the project's <code>sonar.java.source</code> is lower than <code>7</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
File tempDir;
tempDir = File.createTempFile("", ".");
tempDir.delete();
tempDir.mkdir();  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
Path tempPath = Files.createTempDirectory("");
File tempDir = tempPath.toFile();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3510">squid:S3510</a>
					</td>
					<td>
						<details>
							<p>To prevent URL spoofing, <code>HostnameVerifier.verify()</code> methods should do more than simply <code>return true</code>. Doing so may get you
quickly past an exception, but that comes at the cost of opening a security hole in your application. </p>
<h2>Noncompliant Code Example</h2>
<pre>
SSLContext sslcontext = SSLContext.getInstance( "TLS" );
sslcontext.init(null, new TrustManager[]{new X509TrustManager() {
  public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
  public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
  public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }

}}, new java.security.SecureRandom());

Client client = ClientBuilder.newBuilder().sslContext(sslcontext).hostnameVerifier(new HostnameVerifier() {
  @Override
  public boolean verify(String requestedHost, SSLSession remoteServerSession) {
    return true;  // Noncompliant
  }
}).build();
</pre>
<h2>Compliant Solution</h2>
<pre>
SSLContext sslcontext = SSLContext.getInstance( "TLSv1.2" );
sslcontext.init(null, new TrustManager[]{new X509TrustManager() {
  @Override
  public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
  @Override
  public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
  @Override
  public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }

}}, new java.security.SecureRandom());

Client client = ClientBuilder.newBuilder().sslContext(sslcontext).hostnameVerifier(new HostnameVerifier() {
  @Override
  public boolean verify(String requestedHost, SSLSession remoteServerSession) {
    return requestedHost.equalsIgnoreCase(remoteServerSession.getPeerHost()); // Compliant
  }
}).build();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/295.html">MITRE, CWE-295</a> - Improper Certificate Validation </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#WEAK_HOSTNAME_VERIFIER">WEAK_HOSTNAME_VERIFIER</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3752">squid:S3752</a>
					</td>
					<td>
						<details>
							<p>A <code>@RequestMapping</code> method handles all matching requests by default. That means that a method you intended only to be
<code>POST</code>-ed to could also be called by a <code>GET</code>, thereby allowing hackers to call the method inappropriately. For example a
"transferFunds" method might be invoked like so: <code>&lt;img
src="http://bank.com/actions/transferFunds?reciepientRouting=000000&amp;receipientAccount=11111111&amp;amount=200.00" width="1"
height="1"/&gt;</code></p>
<p>For that reason, you should always explicitly list the single HTTP method with which you expect your <code>@RequestMapping</code> Java method to be
called. This rule raises an issue when <code>method</code> is missing and when the <code>method</code> parameter is configured with more than one
verb. Mixing GET and POST verbs can lead to information leakage. It's easier to setup Spring Security’s CSRF protection when there is only one verb
per <code>@RequestMapping</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
@RequestMapping("/greet")  // Noncompliant
public String greet(String greetee) {
</pre>
<h2>Compliant Solution</h2>
<pre>
  @RequestMapping("/greet", method = GET)
  public String greet(String greetee) {
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/352.html">MITRE, CWE-352</a> - Cross-Site Request Forgery (CSRF) </li>
  <li> <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">OWASP: Cross-Site Request Forgery</a> </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> <a href="https://docs.spring.io/spring-security/site/docs/5.0.x/reference/html/csrf.html#csrf-use-proper-verbs">Spring Security Official
  Documentation: Use proper HTTP verbs (CSRF protection)</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4601">squid:S4601</a>
					</td>
					<td>
						<details>
							<p>URL patterns configured on a <code>HttpSecurity.authorizeRequests()</code> method are considered in the order they were declared. It's easy to do a
mistake and to declare a less restrictive configuration before a more restrictive one. Therefore, it's required to review the order of the
"antMatchers" declarations. The <code>/**</code> one should be the last one if it is declared.</p>
<p>This rule raises an issue when:</p>
<p>- A pattern is preceded by another that ends with <code>**</code> and has the same beginning. E.g.: <code>/page*-admin/db/**</code> is after
<code>/page*-admin/**</code></p>
<p>- A pattern without wildcard characters is preceded by another that matches. E.g.: <code>/page-index/db</code> is after <code>/page*/**</code></p>
<h2>Noncompliant Code Example</h2>
<pre>
  protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
      .antMatchers("/resources/**", "/signup", "/about").permitAll() // Compliant
      .antMatchers("/admin/**").hasRole("ADMIN")
      .antMatchers("/admin/login").permitAll() // Noncompliant; the pattern "/admin/login" should occurs before "/admin/**"
      .antMatchers("/**", "/home").permitAll()
      .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')") // Noncompliant; the pattern "/db/**" should occurs before "/**"
      .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
  }
</pre>
<h2>Compliant Solution</h2>
<pre>
  protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
      .antMatchers("/resources/**", "/signup", "/about").permitAll() // Compliant
      .antMatchers("/admin/login").permitAll()
      .antMatchers("/admin/**").hasRole("ADMIN") // Compliant
      .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
      .antMatchers("/**", "/home").permitAll() // Compliant; "/**" is the last one
      .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
  }
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3751">squid:S3751</a>
					</td>
					<td>
						<details>
							<p>A method with a <code>@RequestMapping</code> annotation part of a class annotated with <code>@Controller</code> (directly or indirectly through a
meta annotation - <code>@RestController</code> from Spring Boot is a good example) will be called to handle matching web requests. That will happen
even if the method is <code>private</code>, because Spring invokes such methods via reflection, without checking visibility. </p>
<p>So marking a sensitive method <code>private</code> may seem like a good way to control how such code is called. Unfortunately, not all Spring
frameworks ignore visibility in this way. For instance, if you've tried to control web access to your sensitive, <code>private</code>,
<code>@RequestMapping</code> method by marking it <code>@Secured</code> ... it will still be called, whether or not the user is authorized to access
it. That's because AOP proxies are not applied to non-public methods.</p>
<p>In addition to <code>@RequestMapping</code>, this rule also considers the annotations introduced in Spring Framework 4.3: <code>@GetMapping</code>,
<code>@PostMapping</code>, <code>@PutMapping</code>, <code>@DeleteMapping</code>, <code>@PatchMapping</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
@RequestMapping("/greet", method = GET)
private String greet(String greetee) {  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
@RequestMapping("/greet", method = GET)
public String greet(String greetee) {
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2647">squid:S2647</a>
					</td>
					<td>
						<details>
							<p>Basic authentication's only means of obfuscation is Base64 encoding. Since Base64 encoding is easily recognized and reversed, it offers only the
thinnest veil of protection to your users, and should not be used. </p>
<h2>Noncompliant Code Example</h2>
<pre>
// Using HttpPost from Apache HttpClient
String encoding = Base64Encoder.encode ("login:passwd");
org.apache.http.client.methods.HttpPost httppost = new HttpPost(url);
httppost.setHeader("Authorization", "Basic " + encoding);  // Noncompliant

or

// Using HttpURLConnection
String encoding = Base64.getEncoder().encodeToString(("login:passwd").getBytes(‌"UTF‌​-8"​));
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod("POST");
conn.setDoOutput(true);
conn.setRequestProperty("Authorization", "Basic " + encoding); // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://www.owasp.org/index.php/Basic_Authentication">OWASP Basic Authentication</a> </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/522">MITRE, CWE-522</a> - Insufficiently Protected Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/311">MITRE, CWE-311</a> - Missing Encryption of Sensitive Data </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2653">squid:S2653</a>
					</td>
					<td>
						<details>
							<p>There is no reason to have a <code>main</code> method in a web application. It may have been useful for debugging during application development,
but such a method should never make it into production. Having a <code>main</code> method in a web application opens a door to the application logic
that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be
present.</p>
<p>This rule raises an issue when a <code>main</code> method is found in a servlet or an EJB.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyServlet extends HttpServlet {
  public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
    if (userIsAuthorized(req)) {
      updatePrices(req);
    }
  }

  public static void main(String[] args) { // Noncompliant
    updatePrices(req);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VoB8Bw">CERT, ENV06-J.</a> - Production code must not contain debugging entry points
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3749">squid:S3749</a>
					</td>
					<td>
						<details>
							<p>Spring <code>@Controller</code>, <code>@Service</code>, and <code>@Repository</code> classes are singletons by default, meaning only one instance
of the class is ever instantiated in the application. Typically such a class might have a few <code>static</code> members, such as a logger, but all
non-<code>static</code> members should be managed by Spring. That is, they should have one of these annotations: <code>@Resource</code>,
<code>@Inject</code>, <code>@Autowired</code> or <code>@Value</code>.</p>
<p>Having non-injected members in one of these classes could indicate an attempt to manage state. Because they are singletons, such an attempt is
almost guaranteed to eventually expose data from User1's session to User2. </p>
<p>This rule raises an issue when a singleton <code>@Controller</code>, <code>@Service</code>, or <code>@Repository</code> has non-<code>static</code>
members that are not annotated with one of:</p>
<ul>
  <li> <code>org.springframework.beans.factory.annotation.Autowired</code> </li>
  <li> <code>org.springframework.beans.factory.annotation.Value</code> </li>
  <li> <code>javax.annotation.Inject</code> </li>
  <li> <code>javax.annotation.Resource</code> </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
@Controller
public class HelloWorld {

  private String name = null;

  @RequestMapping("/greet", method = GET)
  public String greet(String greetee) {

    if (greetee != null) {
      this.name = greetee;
    }

    return "Hello " + this.name;  // if greetee is null, you see the previous user's data
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1989">squid:S1989</a>
					</td>
					<td>
						<details>
							<p>Even though the signatures for methods in a servlet include <code>throws IOException, ServletException</code>, it's a bad idea to let such
exceptions be thrown. Failure to catch exceptions in a servlet could leave a system in a vulnerable state, possibly resulting in denial-of-service
attacks, or the exposure of sensitive information because when a servlet throws an exception, the servlet container typically sends debugging
information back to the user. And that information could be very valuable to an attacker. </p>
<p>This rule checks all exceptions in methods named "do*" are explicitly handled in servlet classes.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws IOException, ServletException {
  String ip = request.getRemoteAddr();
  InetAddress addr = InetAddress.getByName(ip); // Noncompliant; getByName(String) throws UnknownHostException
  //...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws IOException, ServletException {
  try {
    String ip = request.getRemoteAddr();
    InetAddress addr = InetAddress.getByName(ip);
    //...
  }
  catch (UnknownHostException uhex) {
    //...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/600.html">MITRE, CWE-600</a> - Uncaught Exception in Servlet </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/s4EVAQ">CERT, ERR01-J.</a> - Do not allow exceptions to expose sensitive information
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2068">squid:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>Noncompliant Code Example</h2>
<pre>
Connection conn = null;
try {
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=steve&amp;password=blue"); // Noncompliant
  String uname = "steve";
  String password = "blue";
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=" + uname + "&amp;password=" + password); // Noncompliant

  java.net.PasswordAuthentication pa = new java.net.PasswordAuthentication("userName", "1234".toCharArray());  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
Connection conn = null;
try {
  String uname = getEncryptedUser();
  String password = getEncryptedPass();
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=" + uname + "&amp;password=" + password);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S5344">squid:S5344</a>
					</td>
					<td>
						<details>
							<p>Storing users' passwords in clear-text in a database is definitely not safe as hackers may have read access to all user accounts stored in the
database. It's common then to hash passwords and only store these hashes in the database. When running the authentication process, the hash of the
password provided by the user is compared to the hash stored in the database. If both matches, the access is granted. </p>
<p>This looks like a perfect solution but some algorithms such as MD5 and its successor, SHA-1, are no longer considered secure, because it is too
easy to create hash collisions with them.</p>
<p>That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new,
same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest
algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>For this reason, when <code>PasswordEncoder</code> is used to authenticate user in a Spring application, it should use a secure algorithm. The
following algorithms are considered not safe and should not be used:</p>
<ul>
  <li> <code>org.springframework.security.authentication.encoding.ShaPasswordEncoder</code> (Spring Security 4.2.x) </li>
  <li> <code>org.springframework.security.authentication.encoding.Md5PasswordEncoder</code> (Spring Security 4.2.x) </li>
  <li> <code>org.springframework.security.crypto.password.LdapShaPasswordEncoder</code> (Spring Security 5.0.x) </li>
  <li> <code>org.springframework.security.crypto.password.Md4PasswordEncoder</code> (Spring Security 5.0.x) </li>
  <li> <code>org.springframework.security.crypto.password.MessageDigestPasswordEncoder</code> (Spring Security 5.0.x) </li>
  <li> <code>org.springframework.security.crypto.password.NoOpPasswordEncoder</code> (Spring Security 5.0.x) </li>
  <li> <code>org.springframework.security.crypto.password.StandardPasswordEncoder</code> (Spring Security 5.0.x) </li>
  <li> <code>org.springframework.security.crypto.scrypt.SCryptPasswordEncoder</code> (Spring Security 5.0.x) </li>
</ul>
<p>Consider using safer alternatives, such as <code>org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder</code> (preferred) or
<code>org.springframework.security.crypto.password.Pbkdf2PasswordEncoder</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
    @Autowired
    public void configureGlobal(AuthenticationManagerBuilder auth, DataSource dataSource) throws Exception {
        auth.jdbcAuthentication()
                .dataSource(dataSource)
                .usersByUsernameQuery("SELECT * FROM users WHERE username = ?")
                .passwordEncoder(new StandardPasswordEncoder()); // Noncompliant
        // OR
        auth.jdbcAuthentication()
                .dataSource(dataSource)
                .usersByUsernameQuery("SELECT * FROM users WHERE username = ?"); // Noncompliant; default uses plain-text
        // OR
        auth.userDetailsService(...); // Noncompliant; default uses plain-text
        // OR
        auth.userDetailsService(...).passwordEncoder(new StandardPasswordEncoder()); // Noncompliant
    }
</pre>
<h2>Compliant Solution</h2>
<pre>
    @Autowired
    public void configureGlobal(AuthenticationManagerBuilder auth, DataSource dataSource) throws Exception {
        auth.jdbcAuthentication()
                .dataSource(dataSource)
                .usersByUsernameQuery("Select * from users where username=?")
                .passwordEncoder(new BCryptPasswordEncoder());
        // or
        auth.userDetailsService(null).passwordEncoder(new BCryptPasswordEncoder());
    }
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> https://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4499">squid:S4499</a>
					</td>
					<td>
						<details>
							<p>This rule raises an issue when:</p>
<p>- a JavaMail's <code>javax.mail.Session</code> is created with a <code>Properties</code> object having no
<code>mail.smtp.ssl.checkserveridentity</code> or <code>mail.smtps.ssl.checkserveridentity</code> not configured to <code>true</code></p>
<p>- a Apache Common Emails's <code>org.apache.commons.mail.SimpleEmail</code> is used with <code>setSSLOnConnect(true)</code> or
<code>setStartTLSEnabled(true)</code> or <code>setStartTLSRequired(true)</code> without a call to <code>setSSLCheckServerIdentity(true)</code></p>
<h2>Noncompliant Code Example</h2>
<pre>
Email email = new SimpleEmail();
email.setSmtpPort(465);
email.setAuthenticator(new DefaultAuthenticator(username, password));
email.setSSLOnConnect(true); // Noncompliant; setSSLCheckServerIdentity(true) should also be called before sending the email
email.send();
</pre>
<pre>
Properties props = new Properties();
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.socketFactory.port", "465");
props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); // Noncompliant; Session is created without having "mail.smtp.ssl.checkserveridentity" set to true
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.port", "465");
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() {
  protected PasswordAuthentication getPasswordAuthentication() {
    return new PasswordAuthentication("username@gmail.com", "password");
  }
});
</pre>
<h2>Compliant Solution</h2>
<pre>
Email email = new SimpleEmail();
email.setSmtpPort(465);
email.setAuthenticator(new DefaultAuthenticator(username, password));
email.setSSLOnConnect(true);
email.setSSLCheckServerIdentity(true); // Compliant
email.send();
</pre>
<pre>
Properties props = new Properties();
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.socketFactory.port", "465");
props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.port", "465");
props.put("mail.smtp.ssl.checkserveridentity", true); // Compliant
Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() {
  protected PasswordAuthentication getPasswordAuthentication() {
    return new PasswordAuthentication("username@gmail.com", "password");
  }
});
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/297.html">CWE-297</a> - Improper Validation of Certificate with Host Mismatch </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2070">squid:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>The following APIs are tracked for use of obsolete crypto algorithms:</p>
<p> * <code>java.security.AlgorithmParameters</code> (JDK)</p>
<p> * <code>java.security.AlgorithmParameterGenerator</code> (JDK)</p>
<p> * <code>java.security.MessageDigest</code> (JDK)</p>
<p> * <code>java.security.KeyFactory</code> (JDK)</p>
<p> * <code>java.security.KeyPairGenerator</code> (JDK)</p>
<p> * <code>java.security.Signature</code> (JDK)</p>
<p> * <code>javax.crypto.Mac</code> (JDK)</p>
<p> * <code>javax.crypto.KeyGenerator</code> (JDK)</p>
<p> * <code>org.apache.commons.codec.digest.DigestUtils</code> (Apache Commons Codec)</p>
<p> * <code>com.google.common.hash.Hashing</code> (Guava)</p>
<p> * <code>org.springframework.security.authentication.encoding.ShaPasswordEncoder</code> (Spring Security 4.2.x)</p>
<p> * <code>org.springframework.security.authentication.encoding.Md5PasswordEncoder</code> (Spring Security 4.2.x)</p>
<p> * <code>org.springframework.security.crypto.password.LdapShaPasswordEncoder</code> (Spring Security 5.0.x)</p>
<p> * <code>org.springframework.security.crypto.password.Md4PasswordEncoder</code> (Spring Security 5.0.x)</p>
<p> * <code>org.springframework.security.crypto.password.MessageDigestPasswordEncoder</code> (Spring Security 5.0.x)</p>
<p> * <code>org.springframework.security.crypto.password.NoOpPasswordEncoder</code> (Spring Security 5.0.x)</p>
<p> * <code>org.springframework.security.crypto.password.StandardPasswordEncoder</code> (Spring Security 5.0.x)</p>
<p>Consider using safer alternatives, such as SHA-256, SHA-3 or adaptive one way functions like bcrypt or PBKDF2.</p>
<h2>Noncompliant Code Example</h2>
<pre>
MessageDigest md = MessageDigest.getInstance("SHA1");  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
MessageDigest md = MessageDigest.getInstance("SHA-256");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
<h2>Deprecated</h2>
<p>This rule is deprecated; use <a href='/coding_rules#rule_key=squid%3AS4790'>S4790</a> instead.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3281">squid:S3281</a>
					</td>
					<td>
						<details>
							<p>Default interceptors, such as application security interceptors, must be listed in the <code>ejb-jar.xml</code> file, or they will not be treated
as default. </p>
<p>This rule applies to projects that contain JEE Beans (any one of <code>javax.ejb.Singleton</code>, <code>MessageDriven</code>,
<code>Stateless</code> or <code>Stateful</code>).</p>
<h2>Noncompliant Code Example</h2>
<pre>
// file: ejb-interceptors.xml
&lt;assembly-descriptor&gt;
 &lt;interceptor-binding&gt; &lt;!-- should be declared in ejb-jar.xml --&gt;
      &lt;ejb-name&gt;*&lt;/ejb-name&gt;
      &lt;interceptor-class&gt;com.myco.ImportantInterceptor&lt;/interceptor-class&gt;&lt;!-- Noncompliant; will NOT be treated as default --&gt;
   &lt;/interceptor-binding&gt;
&lt;/assembly-descriptor&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
// file: ejb-jar.xml
&lt;assembly-descriptor&gt;
 &lt;interceptor-binding&gt;
      &lt;ejb-name&gt;*&lt;/ejb-name&gt;
      &lt;interceptor-class&gt;com.myco.ImportantInterceptor&lt;/interceptor-class&gt;
   &lt;/interceptor-binding&gt;
&lt;/assembly-descriptor&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S4347">squid:S4347</a>
					</td>
					<td>
						<details>
							<p>The <code>java.security.SecureRandom</code> class provides a strong random number generator (RNG) appropriate for cryptography. However, seeding it
with a constant or another predictable value will weaken it significantly. In general, it is much safer to rely on the seed provided by the
<code>SecureRandom</code> implementation.</p>
<p>This rule raises an issue when <code>SecureRandom.setSeed()</code> or <code>SecureRandom(byte[])</code> are called with a seed that is either
of:</p>
<ul>
  <li> a constant </li>
  <li> <code>System.currentTimeMillis()</code> </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
SecureRandom sr = new SecureRandom();
sr.setSeed(123456L); // Noncompliant
int v = sr.next(32);

sr = new SecureRandom("abcdefghijklmnop".getBytes("us-ascii")); // Noncompliant
v = sr.next(32);
</pre>
<h2>Compliant Solution</h2>
<pre>
SecureRandom sr = new SecureRandom();
int v = sr.next(32);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/330.html">MITRE, CWE-330</a> - Use of Insufficiently Random Values </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/332.html">MITRE, CWE-332</a> - Insufficient Entropy in PRNG </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/336.html">MITRE, CWE-336</a> - Same Seed in Pseudo-Random Number Generator (PRNG) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/337.html">MITRE, CWE-337</a> - Predictable Seed in Pseudo-Random Number Generator (PRNG) </li>
  <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/MSC63-J.+Ensure+that+SecureRandom+is+properly+seeded">CERT, MSC63J.</a> - Ensure that
  SecureRandom is properly seeded </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2089">squid:S2089</a>
					</td>
					<td>
						<details>
							<p>The fields in an HTTP request are putty in the hands of an attacker, and you cannot rely on them to tell you the truth about anything. While it may
be safe to store such values after they have been neutralized, decisions should never be made based on their contents.</p>
<p>This rule flags uses of the referer header field.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyServlet extends HttpServlet {
  protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    String referer = request.getHeader("referer");  // Noncompliant
    if(isTrustedReferer(referer)){
      //..
    }
    //...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/807">MITRE, CWE-807</a> - Reliance on Untrusted Inputs in a Security Decision </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/293">MITRE, CWE-293</a> - Using Referer Field for Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S899">squid:S899</a>
					</td>
					<td>
						<details>
							<p>When the return value of a function call contain the operation status code, this value should be tested to make sure the operation completed
successfully.</p>
<p>This rule raises an issue when the return values of the following are ignored:</p>
<ul>
  <li> <code>java.io.File</code> operations that return a status code (except <code>mkdirs</code>) </li>
  <li> <code>Iterator.hasNext()</code> </li>
  <li> <code>Enumeration.hasMoreElements()</code> </li>
  <li> <code>Lock.tryLock()</code> </li>
  <li> non-void <code>Condition.await*</code> methods </li>
  <li> <code>CountDownLatch.await(long, TimeUnit)</code> </li>
  <li> <code>Semaphore.tryAcquire</code> </li>
  <li> <code>BlockingQueue</code>: <code>offer</code>, <code>remove</code> </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public void doSomething(File file, Lock lock) {
  file.delete();  // Noncompliant
  // ...
  lock.tryLock(); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public void doSomething(File file, Lock lock) {
  if (!lock.tryLock()) {
    // lock failed; take appropriate action
  }
  if (!file.delete()) {
    // file delete failed; take appropriate action
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> MISRA C:2004, 16.10 - If a function returns error information, then that error information shall be tested </li>
  <li> MISRA C++:2008, 0-1-7 - The value returned by a function having a non-void return type that is not an overloaded operator shall always be used.
  </li>
  <li> MISRA C:2012, Dir. 4.7 - If a function returns error information, then that error information shall be tested </li>
  <li> MISRA C:2012, 17.7 - The value returned by a function having non-void return type shall be used </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/w4C4Ag">CERT, ERR33-C.</a> - Detect and handle standard library errors </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/iIBfBw">CERT, POS54-C.</a> - Detect and handle POSIX library errors </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/9gEqAQ">CERT, EXP00-J.</a> - Do not ignore values returned by methods </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/9YIRAQ">CERT, EXP12-C.</a> - Do not ignore values returned by functions </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/toHWAw">CERT, FIO02-J.</a> - Detect and handle file-related errors </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/754">MITRE, CWE-754</a> - Improper Check for Unusual Exceptional Conditions </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=tsql:S2068">tsql:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=tsql:S2070">tsql:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>Consider using safer alternatives, such as SHA-256, or SHA-3.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SELECT HASHBYTES('SHA1', MyColumn) FROM dbo.MyTable;
</pre>
<h2>Compliant Solution</h2>
<pre>
SELECT HASHBYTES('SHA2_256', MyColumn) FROM dbo.MyTable;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S4426">csharpsquid:S4426</a>
					</td>
					<td>
						<details>
							<p>When generating cryptograpic keys (or key pairs), it is important to use a key length that provides enough entropy against brute-force attacks. For
the RSA algorithm the key should be at </p>
<p> least 2048 bits long.</p>
<p>This rule raises an issue when a RSA key-pair generator is initialized with too small a length parameter.</p>
<h2>Noncompliant Code Example</h2>
<pre>
using System;
using System.Security.Cryptography;

namespace MyLibrary
{
    public class MyCryptoClass
    {
        static void Main()
        {
            RSACryptoServiceProvider RSA = new RSACryptoServiceProvider(1024); // Noncompliant
            // ...
        }
    }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
using System;
using System.Security.Cryptography;

namespace MyLibrary
{
    public class MyCryptoClass
    {
        static void Main()
        {
            RSACryptoServiceProvider RSA = new RSACryptoServiceProvider(2048);
            // ...
        }
    }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#BLOWFISH_KEY_SIZE">BLOWFISH_KEY_SIZE</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#RSA_KEY_SIZE">RSA_KEY_SIZE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S3330">csharpsquid:S3330</a>
					</td>
					<td>
						<details>
							<p>The <code>HttpOnly</code> cookie attribute tells the browser to prevent client-side scripts from reading cookies with the attribute, and its use
can go a long way to defending against Cross-Site Scripting (XSS) attacks. Thus, as a precaution, the attribute should be set by default on all
cookies set server-side, such as session id cookies.</p>
<p>When implementing Cross Site Request Forgery (XSRF) protection, a JavaScript-readable session cookie, generally named XSRF-TOKEN, should be created
on the first HTTP GET request. For such a cookie, the <code>HttpOnly</code> attribute should be set to "false".</p>
<p>Setting the attribute can be done either programmatically, or globally via configuration files. </p>
<h2>Noncompliant Code Example</h2>
<pre>
HttpCookie myCookie = new HttpCookie("UserSettings");
myCookie.HttpOnly = false; // Noncompliant; explicitly set to false
...
Response.Cookies.Add(myCookie);
</pre>
<pre>
HttpCookie myCookie = new HttpCookie("UserSettings"); // Noncompliant; the default value of 'HttpOnly' is used (=false)
...
Response.Cookies.Add(myCookie);
</pre>
<h2>Compliant Solution</h2>
<pre>
HttpCookie myCookie = new HttpCookie("UserSettings");
myCookie.HttpOnly = true; // Compliant
...
Response.Cookies.Add(myCookie);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HttpOnly">OWASP HttpOnly</a> </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79</a> - Improper Neutralization of Input During Web Page Generation ('Cross-site
  Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/1004.html">CWE-1004</a> - Sensitive Cookie Without 'HttpOnly' Flag </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#HTTPONLY_COOKIE">HTTPONLY_COOKIE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S2070">csharpsquid:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6.</p>
<p>This rule tracks usage of the <code>System.Security.Cryptography.CryptoConfig.CreateFromName()</code>, and
<code>System.Security.Cryptography.HashAlgorithm.Create()</code> methods to instantiate MD5, DSA, HMACMD5, HMACRIPEMD160, RIPEMD-160 or SHA-1
algorithms, and of derived class instances of <code>System.Security.Cryptography.SHA1</code> and <code>System.Security.Cryptography.MD5</code>.</p>
<p>Consider using safer alternatives, such as SHA-256, or SHA-3.</p>
<h2>Noncompliant Code Example</h2>
<pre>
var hashProvider1 = new MD5CryptoServiceProvider(); //Noncompliant
var hashProvider2 = (HashAlgorithm)CryptoConfig.CreateFromName("MD5"); //Noncompliant
var hashProvider3 = new SHA1Managed(); //Noncompliant
var hashProvider4 = HashAlgorithm.Create("SHA1"); //Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
var hashProvider1 = new SHA256Managed();
var hashProvider2 = (HashAlgorithm)CryptoConfig.CreateFromName("SHA256Managed");
var hashProvider3 = HashAlgorithm.Create("SHA256Managed");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
<h2>Deprecated</h2>
<p>This rule is deprecated; use <a href='/coding_rules#rule_key=csharpsquid%3AS4790'>S4790</a> instead.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2115">php:S2115</a>
					</td>
					<td>
						<details>
							<p>Failure to password-protect a database is so careless or naive as to be almost negligent. Databases should always be password protected, but the
use of a database connection with an empty password is a clear indication of a database that is not protected.</p>
<p>This rule flags database connections with empty passwords.</p>
<h2>Noncompliant Code Example</h2>
<pre>
&lt;?php
  $servername = "localhost";
  $username = "AppLogin";
  $password = "";

  // MySQL
  $conn = new mysqli($servername, $username, $password);
  // MySQL
  $conn = mysqli_connect($servername, $username, $password);
  // PDO way
  $conn = new PDO("mysql:host=$servername;dbname=myDB", $username, $password);
  // Oracle
  $conn = oci_connect($username, $password, "//localhost/orcl");
  // MS SQL Server
  $sqlsrvName = "serverName\sqlexpress";
  $sqlsrvConnInfo = array( "Database"=&gt;"myDB", "UID"=&gt;$username, "PWD"=&gt;$password);
  $conn = sqlsrv_connect( $sqlsrvName, $sqlsrvConnInfo);
  // PosgreSQL
  $pgConnInfo = "host=localhost port=5432 dbname=test user=" . $username . " password=" . $password;
  $conn = pg_connect($pgConnInfo);
?&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/521.html">MITRE, CWE-521</a> - Weak Password Requirements </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2070">php:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>Consider using safer alternatives, such as SHA-256, or SHA-3.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$password = ...

if (md5($password) === '1f3870be274f6c49b3e31a0c6728957f') { // Noncompliant; md5() hashing algorithm is not secure for password management
   [...]
}

if (sha1($password) === 'd0be2dc421be4fcd0172e5afceea3970e2f3d940') { // Noncompliant; sha1() hashing algorithm is not secure for password management
   [...]
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
<h2>Deprecated</h2>
<p>This rule is deprecated; use <a href='/coding_rules#rule_key=php%3AS4790'>S4790</a> instead.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2964">php:S2964</a>
					</td>
					<td>
						<details>
							<p><code>sleep</code> is sometimes used in a mistaken attempt to prevent Denial of Service (DoS) attacks by throttling response rate. But because it
ties up a thread, each request takes longer to serve that it otherwise would, making the application <em>more</em> vulnerable to DoS attacks, rather
than less.</p>
<h2>Noncompliant Code Example</h2>
<pre>
if (is_bad_ip($requester)) {
  sleep(5);  // Noncompliant
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2053">php:S2053</a>
					</td>
					<td>
						<details>
							<p>In cryptography, "salt" is extra piece of data which is included in a hashing algorithm. It makes dictionary attacks more difficult. Using a
cryptographic hash function without an unpredictable salt increases the likelihood that an attacker will be able to successfully guess a hashed value
such as a password with a dictionary attack.</p>
<p>This rule raises an issue when a hashing function which has been specifically designed for hashing sensitive data, such as pbkdf2, is used with a
non-random, reused or too short salt value. It does not raise an issue on base hashing algorithms such as sha1 or md5 as these are often used for
other purposes.</p>
<h2>Recommended Secure Coding Practices</h2>
<ul>
  <li> use hashing functions generating their own salt or generate a long random salt of at least 32 bytes. </li>
  <li> the salt is at least as long as the resulting hash value. </li>
  <li> provide the salt to a safe hashing function such as PBKDF2. </li>
  <li> save both the salt and the hashed value in the relevant database record; during future validation operations, the salt and hash can then be
  retrieved from the database. The hash is recalculated with the stored salt and the value being validated, and the result compared to the stored
  hash. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
function createMyAccount() {
  $email = $_GET['email'];
  $name = $_GET['name'];
  $password = $_GET['password'];

  $hash = hash_pbkdf2('sha256', $password, $email, 100000); // Noncompliant; salt (3rd argument) is predictable because initialized with the provided $email

  $hash = hash_pbkdf2('sha256', $password, '', 100000); // Noncompliant; salt is empty

  $hash = hash_pbkdf2('sha256', $password, 'D8VxSmTZt2E2YV454mkqAY5e', 100000); // Noncompliant; salt is hardcoded

  $hash = crypt($password); // Noncompliant; salt is not provided
  $hash = crypt($password, ""); // Noncompliant; salt is hardcoded

  $options = [
    'cost' =&gt; 11,
    'salt' =&gt; mcrypt_create_iv(22, MCRYPT_DEV_URANDOM), // Noncompliant ; use salt generated by default
  ];
  echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
}
</pre>
<h2>Compliant Solution</h2>
<pre>
$salt = openssl_random_pseudo_bytes(16);
$hash = hash_pbkdf2("sha256", $password, $salt, $iterations, 20);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/759.html">MITRE, CWE-759</a> - Use of a One-Way Hash without a Salt </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/760.html">MITRE, CWE-760</a> - Use of a One-Way Hash with a Predictable Salt </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2277">php:S2277</a>
					</td>
					<td>
						<details>
							<p>Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an
issue when <code>openssl_public_encrypt</code> is used with one the following padding constants: <code>OPENSSL_NO_PADDING</code> or
<code>OPENSSL_PKCS1_PADDING</code> or <code>OPENSSL_SSLV23_PADDING</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_NO_PADDING); // Noncompliant
  return $crypted;
}
</pre>
<h2>Compliant Solution</h2>
<pre>
function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_PKCS1_OAEP_PADDING);
  return $crypted;
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/780.html">MITRE CWE-780</a> - Use of RSA Algorithm without OAEP </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#RSA_NO_PADDING">RSA NoPadding Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3336">php:S3336</a>
					</td>
					<td>
						<details>
							<p>PHP's <code>session.use_trans_sid</code> automatically appends the user's session id to urls when cookies are disabled. On the face of it, this
seems like a nice way to let uncookie-able users use your site anyway. In reality, it makes those users vulnerable to having their sessions hijacked
by anyone who might:</p>
<ul>
  <li> see the URL over the user's shoulder </li>
  <li> be sent the URL by the user </li>
  <li> retrieve the URL from browser history </li>
  <li> ... </li>
</ul>
<p>For that reason, it's better to practice a little "tough love" with your users and force them to turn on cookies.</p>
<p>Since <code>session.use_trans_sid</code> is off by default, this rule raises an issue when it is explicitly enabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
session.use_trans_sid=1  ; Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3337">php:S3337</a>
					</td>
					<td>
						<details>
							<p><code>enable_dl</code> is on by default and allows <code>open_basedir</code> restrictions, which limit the files a script can access, to be
ignored. For that reason, it's a dangerous option and should be explicitly turned off.</p>
<p>This rule raises an issue when <code>enable_dl</code> is not explicitly set to 0 in <em>php.ini</em>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
enable_dl=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
enable_dl=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/23.html">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/36.html">MITRE, CWE-36</a> - Absolute Path Traversal </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S4423">php:S4423</a>
					</td>
					<td>
						<details>
							<p>Not all SSL protocols are created equal and some legacy ones like "SSL", have been proven to be insecure.</p>
<p>This rule raises an issue when an SSL context is created with an insecure protocol (ie: a protocol different from "TLSv1.2" or "DTLSv1.2").</p>
<h2>Noncompliant Code Example</h2>
<pre>
$ctx = stream_context_create([
  'ssl' =&gt; [
    'crypto_method' =&gt;
      STREAM_CRYPTO_METHOD_TLSv1_1_CLIENT // Noncompliant
  ],
]);
</pre>
<h2>Compliant Solution</h2>
<pre>
$ctx = stream_context_create([
    'ssl' =&gt; [
        'crypto_method' =&gt; STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT
    ],
]);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-327</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-326</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https">Diagnosing TLS, SSL, and HTTPS</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3334">php:S3334</a>
					</td>
					<td>
						<details>
							<p><code>allow_url_fopen</code> and <code>allow_url_include</code> allow code to be read into a script from URL's. The ability to suck in executable
code from outside your site, coupled with imperfect input cleansing could lay your site bare to attackers. Even if your input filtering is perfect
today, are you prepared to bet your site that it will always be perfect in the future?</p>
<p>This rule raises an issue when either property is explicitly enabled in <em>php.ini</em> and when <code>allow_url_fopen</code>, which defaults to
enabled, is not explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini  Noncompliant; allow_url_fopen not explicitly disabled
allow_url_include=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
allow_url_fopen=0
allow_url_include=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/829.html">MITRE, CWE-829</a> - Inclusion of Functionality from Untrusted Control Sphere </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S4426">php:S4426</a>
					</td>
					<td>
						<details>
							<p>When generating cryptographic keys (or key pairs), it is important to use a key length that provides enough entropy against brute-force attacks.
For the RSA algorithm, it should be at least 2048 bits long.</p>
<p>This rule raises an issue when an RSA key-pair generator is initialized with too small a length parameter.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$config = array(
    "digest_alg" =&gt; "sha512",
    "private_key_bits" =&gt; 1024, // Noncompliant
    "private_key_type" =&gt; OPENSSL_KEYTYPE_RSA,
);
$res = openssl_pkey_new($config);
</pre>
<h2>Compliant Solution</h2>
<pre>
$config = array(
    "digest_alg" =&gt; "sha512",
    "private_key_bits" =&gt; 4096, // Compliant
    "private_key_type" =&gt; OPENSSL_KEYTYPE_RSA,
);
$res = openssl_pkey_new($config);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#BLOWFISH_KEY_SIZE">BLOWFISH_KEY_SIZE</a> </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#RSA_KEY_SIZE">RSA_KEY_SIZE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3335">php:S3335</a>
					</td>
					<td>
						<details>
							<p>The <code>cgi.force_redirect</code> <em>php.ini</em> configuration is on by default, and it prevents unauthenticated access to scripts when PHP is
running as a CGI. Unfortunately, it must be disabled on IIS, OmniHTTPD and Xitami, but in all other cases it should be on.</p>
<p>This rule raises an issue when when <code>cgi.force_redirect</code> is explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
cgi.force_redirect=0  ; Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/305">MITRE, CWE-305</a> - Authentication Bypass by Primary Weakness </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3332">php:S3332</a>
					</td>
					<td>
						<details>
							<p>Cookies without fixed lifetimes or expiration dates are known as non-persistent, or "session" cookies, meaning they last only as long as the
browser session, and poof away when the browser closes. Cookies with expiration dates, "persistent" cookies, are stored/persisted until those
dates.</p>
<p>Non-persistent cookies should be used for the management of logged-in sessions on web sites. To make a cookie non-persistent, simply omit the
<code>expires</code> attribute.</p>
<p>This rule raises an issue when <code>expires</code> is set for a session cookie, either programmatically or via configuration, such as
<code>session.cookie_lifetime</code>.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Expire_and_Max-Age_Attributes">OWASP, Session Management Cheat
  Sheet</a> - Expire and Max-Age Attributes </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#COOKIE_PERSISTENT">COOKIE_PERSISTENT</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3333">php:S3333</a>
					</td>
					<td>
						<details>
							<p>The <code>open_basedir</code> configuration in <em>php.ini</em> limits the files the script can access using, for example, <code>include</code> and
<code>fopen()</code>. Leave it out, and there is no default limit, meaning that any file can be accessed. Include it, and PHP will refuse to access
files outside the allowed path.</p>
<p><code>open_basedir</code> should be configured with a directory, which will then be accessible recursively. However, the use of <code>.</code>
(current directory) as an <code>open_basedir</code> value should be avoided since it's resolved dynamically during script execution, so a
<code>chdir('/')</code> command could lay the whole server open to the script.</p>
<p>This is not a fool-proof configuration; it can be reset or overridden at the script level. But its use should be seen as a minimum due diligence
step. This rule raises an issue when <code>open_basedir</code> is not present in <em>php.ini</em>, and when <code>open_basedir</code> contains root,
or the current directory (<code>.</code>) symbol.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini try 1
; open_basedir="${USER}/scripts/data"  Noncompliant; commented out

; php.ini try 2
open_basedir="/:${USER}/scripts/data"  ; Noncompliant; root directory in the list
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini try 1
open_basedir="${USER}/scripts/data"
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/23.html">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/36.html">MITRE, CWE-36</a> - Absolute Path Traversal </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3330">php:S3330</a>
					</td>
					<td>
						<details>
							<p>The <code>HttpOnly</code> cookie attribute tells the browser to prevent client-side scripts from reading cookies with the attribute, and its use
can go a long way to defending against Cross-Site Scripting (XSS) attacks. Thus, as a precaution, the attribute should be set by default on all
cookies set server-side, such as session id cookies.</p>
<p>Setting the attribute can be done either programmatically, or globally via configuration files. </p>
<p>This rule raises an issue:</p>
<ul>
  <li> when <code>HttpOnly</code> is missing from <code>php.ini</code> or explicitly set to false </li>
  <li> when <code>setcookie()</code>'s last parameter is explicitly set to false </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
session.cookie_httponly=false  ; Noncompliant; explicitly set to false

// file.php
setcookie($name, $value, $expire, $path, $domain, $secure, false);  // Noncompliant; explicitly set to false
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HttpOnly">OWASP HttpOnly</a> </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79</a> - Improper Neutralization of Input During Web Page Generation ('Cross-site
  Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/1004.html">CWE-1004</a> - Sensitive Cookie Without 'HttpOnly' Flag </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> Derived from FindSecBugs rule <a href="https://find-sec-bugs.github.io/bugs.htm#HTTPONLY_COOKIE">HTTPONLY_COOKIE</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3338">php:S3338</a>
					</td>
					<td>
						<details>
							<p><code>file_uploads</code> is an on-by-default PHP configuration that allows files to be uploaded to your site. Since accepting <del>candy</del>
files from strangers is inherently dangerous, this feature should be disabled unless it is absolutely necessary for your site.</p>
<p>This rule raises an issue when <code>file_uploads</code> is not explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
file_uploads=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
file_uploads=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/434.html">MITRE, CWE-434</a> - Unrestricted Upload of File with Dangerous Type </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S4830">php:S4830</a>
					</td>
					<td>
						<details>
							<p>Disabling SSL/TLS certificates chain of trust verification is similar to trust every one in the chain and so to expose the application to
man-in-the-middle (MITM) attacks.</p>
<h2>Noncompliant Code Example</h2>
<pre>
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, TRUE); // Noncompliant; TRUE is casted to 1 which is not a secure configuration
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);

// and/or

curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
</pre>
<h2>Compliant Solution</h2>
<pre>
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2); // Compliant; default value is 2 to "check the existence of a common name and also verify that it matches the hostname provided" according to PHP's documentation

// and/or

curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, TRUE); // Compliant; default value is TRUE
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 1);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration">OWASP Top 10 2017 Category A6</a> - Security
  Misconfiguration </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/295.html">MITRE, CWE-295</a> - Improper Certificate Validation </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S2631">javasecurity:S2631</a>
					</td>
					<td>
						<details>
							<p>Evaluating regular expressions against input strings can be an extremely CPU-intensive task. For example, a specially crafted regular expression
such as <code>(a+)++</code> will take several seconds to evaluate the input string,&nbsp;<code>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!</code>. The problem is
that every additional "<code>a"</code> added to the input doubles the time required to evaluate the regex. However, the equivalent regular expression,
<code>a</code> (without grouping), is efficiently evaluated in milliseconds and scales linearly with the input size.</p>
<p>Evaluating user-provided strings as regular expressions opens the door for Denial Of Service attacks. In the context of a web application,
attackers can force the web server to spend all of its resources evaluating regular expressions thereby making the service inaccessible to genuine
users.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public boolean validate(javax.servlet.http.HttpServletRequest request) {
  String regex = request.getParameter("regex");
  String input = request.getParameter("input");

  // Enables attackers to force the web server to evaluate
  // regex such as "(a+)+" on inputs such as "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!"

  input.matches(regex);  // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public boolean validate(javax.servlet.http.HttpServletRequest request) {
  String input = request.getParameter("input");

  input.matches("a+");  // Compliant - use a safe hardcoded regex
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/400">MITRE, CWE-400</a> - Uncontrolled Resource Consumption </li>
  <li> <a href="https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS">OWASP Regular expression Denial of Service - ReDoS</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5146">javasecurity:S5146</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
performing HTTP redirects based on tainted data could enable an attacker to redirect users to a malicious site to, for example, steal login
credentials.</p>
<p>This problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not perform redirects based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String location = req.getParameter("url");
  resp.sendRedirect(location); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String location = req.getParameter("url");

  // Match the incoming URL against a whitelist
  if (!urlWhiteList.contains(location))
    throw new IOException();

  resp.sendRedirect(location);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/601.html">MITRE, CWE-601</a> - URL Redirection to Untrusted Site ('Open Redirect') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S2078">javasecurity:S2078</a>
					</td>
					<td>
						<details>
							<p>User provided data such as URL parameters should always be considered as untrusted and tainted. Constructing LDAP names or search filters directly
from tainted data enables attackers to inject specially crafted values that changes the initial meaning of the name or filter itself. Successful LDAP
injections attacks can read, modify or delete sensitive information from the directory service.</p>
<p>Within LDAP names, the special characters <code>' '</code>, <code>'#'</code>, <code>'"'</code>, <code>'+'</code>, <code>','</code>,
<code>';'</code>, <code>'&lt;'</code>, <code>'&gt;'</code>, <code>'\'</code> and <code>null</code> must be escaped according to RFC 4514, for example
by replacing them with the backslash character <code>'\'</code> followed by the two hex digits corresponding to the ASCII code of the character to be
escaped. Similarly, LDAP search filters must escape a different set of special characters (including but not limited to <code>'*'</code>,
<code>'('</code>, <code>')'</code>, <code>'\'</code> and <code>null</code>) according to RFC 4515.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, DirContext ctx) throws NamingException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String filter = "(&amp;(uid=" + user + ")(userPassword=" + pass + "))"; // Unsafe

  // If the special value "*)(uid=*))(|(uid=*" is passed as user, authentication is bypassed
  // Indeed, if it is passed as a user, the filter becomes:
  // (&amp;(uid=*)(uid=*))(|(uid=*)(userPassword=...))
  // as uid=* match all users, it is equivalent to:
  // (|(uid=*)(userPassword=...))
  // again, as uid=* match all users, the filter becomes useless

  NamingEnumeration&lt;SearchResult&gt; results = ctx.search("ou=system", filter, new SearchControls()); // Noncompliant
  return results.hasMore();
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, DirContext ctx) throws NamingException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String filter = "(&amp;(uid={0})(userPassword={1}))"; // Safe

  NamingEnumeration&lt;SearchResult&gt; results = ctx.search("ou=system", filter, new String[]{user, pass}, new SearchControls());
  return results.hasMore();
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4514.txt">RFC 4514</a> - LDAP: String Representation of Distinguished Names </li>
  <li> <a href="https://www.ietf.org/rfc/rfc4515.txt">RFC 4515</a> - LDAP: String Representation of Search Filters </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/90">MITRE CWE-90</a> - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP
  Injection') </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/CgLEAw">CERT, IDS54-J.</a> - Prevent LDAP injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5145">javasecurity:S5145</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads or cookies, should always be considered untrusted and tainted. Applications logging
tainted data could enable an attacker to inject characters that would break the log file pattern. This could be used to block monitors and SIEM
(Security Information and Event Management) systems from detecting other malicious events.</p>
<p>This problem could be mitigated by sanitizing the user provided data before logging it.</p>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String param1 = req.getParameter("param1");
  Logger.info("Param1: " + param1 + " " + Logger.getName()); // Noncompliant
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String param1 = req.getParameter("param1");

  // Replace pattern-breaking characters
  param1 = param1.replaceAll("[\n|\r|\t]", "_");

  Logger.info("Param1: " + param1 + " " + Logger.getName());
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Logging_Cheat_Sheet">OWASP Cheat Sheet</a> - Logging </li>
  <li> <a href="https://www.owasp.org/index.php/Log_Injection">OWASP Attack Category</a> - Log Injection </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/117.html">MITRE, CWE-117</a> - Improper Output Neutralization for Logs </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5167">javasecurity:S5167</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
constructing HTTP response headers based on tainted data could allow attackers to inject characters that would be interpreted as a new line in some
browsers. This could, for example, enable Cross-Site Scripting (XSS) attacks.</p>
<p>Most modern web application frameworks and servers mitigate this type of attack by default, but there might be rare cases where older versions are
still vulnerable. As a best practice, applications that use user provided data to construct the response header should always validate the data first.
Validation should be based on a whitelist.</p>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String value = req.getParameter("value");
  resp.addHeader("X-Header", value); // Noncompliant
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String value = req.getParameter("value");

  // Allow only alphanumeric characters
  if (!value.matches("[a-zA-Z0-9]++"))
    throw new IOException();

  resp.addHeader("X-Header", value);
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">OWASP Attack Category</a> - HTTP Response Splitting </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/113.html">MITRE, CWE-113</a> - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP
  Response Splitting') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S2076">javasecurity:S2076</a>
					</td>
					<td>
						<details>
							<p>Applications that execute operating system commands or execute commands that interact with the underlying system should neutralize any
externally-provided values used in those commands. Failure to do so could allow an attacker to include input that executes unintended commands or
exposes sensitive data.</p>
<p>The mitigation strategy should be based on whitelisting of allowed characters or commands.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public void run(javax.servlet.http.HttpServletRequest request) throws IOException {
  String binary = request.getParameter("binary");

  // If the value "/sbin/shutdown" is passed as binary and the web server is running as root,
  // then the machine running the web server will be shut down and become unavailable for future requests

  Runtime.getRuntime().exec(binary); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public void run(javax.servlet.http.HttpServletRequest request) throws IOException {
  String binary = request.getParameter("binary");

  // Restrict to binaries within the current working directory whose name only contains letters
  if (!binary.matches("[a-zA-Z]++")) {
    throw new IllegalArgumentException();
  }

  Runtime.getRuntime().exec(binary);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/78">MITRE, CWE-78</a> - Improper Neutralization of Special Elements used in an OS Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/88">MITRE, CWE-88</a> - Argument Injection or Modification </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5131">javasecurity:S5131</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Endpoints reflecting
back tainted data could allow attackers to inject code that would eventually be executed in the user's browser. This could enable a wide range of
serious attacks like accessing/modifying sensitive information or impersonating other users.</p>
<p>Typically, the solution is one of the following:</p>
<ul>
  <li> Validate user provided data based on a whitelist and reject input that's not whitelisted. </li>
  <li> Sanitize user provided data from any characters that can be used for malicious purposes. </li>
  <li> Encode user provided data being reflected as output. Adjust the encoding to the output context so that, for example, HTML encoding is used for
  HTML content, HTML attribute encoding is used for attribute values, and JavaScript encoding is used for server-generated JavaScript. </li>
</ul>
<p>When sanitizing or encoding data, it is recommended to only use libraries specifically designed for security purposes. Also, make sure that the
library you are using is being actively maintained and is kept up-to-date with the latest discovered vulnerabilities.</p>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String name = req.getParameter("name");
  PrintWriter out = resp.getWriter();
  out.write("Hello " + name); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String name = req.getParameter("name");
  String encodedName = org.owasp.encoder.Encode.forHtml(name);
  PrintWriter out = resp.getWriter();
  out.write("Hello " + encodedName);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md">OWASP Cheat
  Sheet</a> - XSS Prevention Cheat Sheet </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/80.html">MITRE, CWE-80</a> - Improper Neutralization of Script-Related HTML Tags in a Web Page
  (Basic XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/81.html">MITRE, CWE-81</a> - Improper Neutralization of Script in an Error Message Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/82.html">MITRE, CWE-82</a> - Improper Neutralization of Script in Attributes of IMG Tags in a
  Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/83.html">MITRE, CWE-83</a> - Improper Neutralization of Script in Attributes in a Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/84.html">MITRE, CWE-84</a> - Improper Neutralization of Encoded URI Schemes in a Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/85.html">MITRE, CWE-85</a> - Doubled Character XSS Manipulations </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/86.html">MITRE, CWE-86</a> - Improper Neutralization of Invalid Characters in Identifiers in
  Web Pages </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/87.html">MITRE, CWE-87</a> - Improper Neutralization of Alternate XSS Syntax </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S5144">javasecurity:S5144</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. A remote server
making requests to URLs based on tainted data could enable attackers to make arbitrary requests to the internal network or to the local file
system.</p>
<p>The problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not send requests based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  URL url = new URL(req.getParameter("url"));
  HttpURLConnection conn = (HttpURLConnection) url.openConnection(); // Noncompliant
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  URL url = new URL(req.getParameter("url"));

  // The safest way is to match the incoming URL against a whitelist
  if (!urlWhiteList.contains(url.toString()))
    throw new IOException();

  // If whitelisting is not possible, at least make sure that things like file:// and http://localhost are blocked
  InetAddress inetAddress = InetAddress.getByName(url.getHost());
  if (!url.getProtocol().startsWith("http") ||
      inetAddress.isAnyLocalAddress() ||
      inetAddress.isLoopbackAddress() ||
      inetAddress.isLinkLocalAddress())
    throw new IOException();

  HttpURLConnection conn = (HttpURLConnection) url.openConnection();
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">OWASP Attack Category</a> - Server Side Request Forgery </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/918.html">MITRE, CWE-918</a> - Server-Side Request Forgery (SSRF) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S2083">javasecurity:S2083</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Constructing file
system paths directly from tainted data could enable an attacker to inject specially crafted values, such as <code>'../'</code>, that change the
initial path and, when accessed, resolve to a path on the filesystem where the user should normally not have access.</p>
<p>A successful attack might give an attacker the ability to read, modify, or delete sensitive information from the file system and sometimes even
execute arbitrary operating system commands. This is often referred to as a "path traversal" or "directory traversal" attack.</p>
<p>The mitigation strategy should be based on the whitelisting of allowed paths or characters.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request) {
  String user = request.getParameter("user");

  // If the special value "../bin" is passed as user, authentication is bypassed
  // Indeed, if it passed as a user, the path becomes:
  // /bin
  // which exists on most Linux / BSD / Mac OS distributions

  return Files.exists(Paths.get("/home/", user)); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request) {
  String user = request.getParameter("user");

  // Restrict the username to letters and digits only
  if (!user.matches("[a-zA-Z0-9]++")) {
    return false;
  }

  return Files.exists(Paths.get("/home/", user));
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/22">MITRE, CWE-22</a> - Improper Limitation of a Pathname to a Restricted Directory ('Path
  Traversal') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/23">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/36">MITRE, CWE-36</a> - Absolute Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/99">MITRE, CWE-99</a> - Improper Control of Resource Identifiers ('Resource Injection') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=javasecurity:S2091">javasecurity:S2091</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, should always be considered untrusted and tainted. Constructing XPath expressions directly from tainted
data enables attackers to inject specially crafted values that changes the initial meaning of the expression itself. Successful XPath injection
attacks can read sensitive information from XML documents.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, javax.xml.xpath.XPath xpath, org.w3c.dom.Document doc) throws XPathExpressionException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String expression = "/users/user[@name='" + user + "' and @pass='" + pass + "']"; // Unsafe

  // An attacker can bypass authentication by setting user to this special value
  user = "' or 1=1 or ''='";

  return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public boolean authenticate(javax.servlet.http.HttpServletRequest request, javax.xml.xpath.XPath xpath, org.w3c.dom.Document doc) throws XPathExpressionException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String expression = "/users/user[@name=$user and @pass=$pass]";

  xpath.setXPathVariableResolver(v -&gt; {
    switch (v.getLocalPart()) {
      case "user":
        return user;
      case "pass":
        return pass;
      default:
        throw new IllegalArgumentException();
    }
  });

  return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/643">MITRE, CWE-643</a> - Improper Neutralization of Data within XPath Expressions </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/BwLEAw">CERT, IDS53-J.</a> - Prevent XPath Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S2631">roslyn.sonaranalyzer.security.cs:S2631</a>
					</td>
					<td>
						<details>
							<p>Evaluating regular expressions against input strings can be an extremely CPU-intensive task. For example, a specially crafted regular expression
such as <code>(a+)++</code> will take several seconds to evaluate the input string,&nbsp;<code>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!</code>. The problem is
that every additional "<code>a"</code> added to the input doubles the time required to evaluate the regex. However, the equivalent regular expression,
<code>a</code> (without grouping), is efficiently evaluated in milliseconds and scales linearly with the input size.</p>
<p>Evaluating user-provided strings as regular expressions opens the door for Denial Of Service attacks. In the context of a web application,
attackers can force the web server to spend all of its resources evaluating regular expressions thereby making the service inaccessible to genuine
users.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class RegexDoS : Controller
{
  // GET /RegexDoS/Validate
  public IActionResult Validate(string regex, string input)
  {
    // Enables attackers to force the web server to evaluate
    // regex such as "^(a+)+$" on inputs such as "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!"

    bool match = Regex.IsMatch(input, regex); // Noncompliant

    return Content("Valid? " + match);
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class RegexDoS : Controller
{
  // GET /RegexDoS/Validate
  public IActionResult Validate(string regex, string input)
  {
    // Option 1: Use a hardcoded regex
    bool match = Regex.IsMatch(input, "^a+$");

    // Option 2: Set a timeout on the regex's evaluation
    match = new Regex(regex, RegexOptions.None, TimeSpan.FromMilliseconds(100)).IsMatch(input);

    return Content("Valid? " + match);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/400">MITRE, CWE-400</a> - Uncontrolled Resource Consumption </li>
  <li> <a href="https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS">OWASP Regular expression Denial of Service - ReDoS</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S5146">roslyn.sonaranalyzer.security.cs:S5146</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
performing HTTP redirects based on tainted data could enable an attacker to redirect users to a malicious site to, for example, steal login
credentials.</p>
<p>This problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not perform redirects based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public class OpenRedirect : Controller
{
  public IActionResult Test(string url)
  {
    return Redirect(url); // Noncompliant
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class OpenRedirect : Controller
{
  private string[] whiteList = { "https://www.sonarsource.com" };

  public IActionResult Test(string url)
  {
    // Match the incoming URL against a whitelist
    if (!whiteList.Contains(url))
    {
      return BadRequest();
    }

    return Redirect(url);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/601.html">MITRE, CWE-601</a> - URL Redirection to Untrusted Site ('Open Redirect') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S5145">roslyn.sonaranalyzer.security.cs:S5145</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads or cookies, should always be considered untrusted and tainted. Applications logging
tainted data could enable an attacker to inject characters that would break the log file pattern. This could be used to block monitors and SIEM
(Security Information and Event Management) systems from detecting other malicious events.</p>
<p>This problem could be mitigated by sanitizing the user provided data before logging it.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class LogForging : Controller
{
  public IActionResult Test(string id)
  {
    logger.Info("ID: {0}", id); // Noncompliant
    // ...
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class LogForging : Controller
{
  public IActionResult Test(string id)
  {
    // Replace pattern-breaking characters
    id = id.Replace('\n', '_').Replace('\r', '_').Replace('\t', '_');

    logger.Info("ID: {0}", id);
    // ...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Logging_Cheat_Sheet">OWASP Cheat Sheet</a> - Logging </li>
  <li> <a href="https://www.owasp.org/index.php/Log_Injection">OWASP Attack Category</a> - Log Injection </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/117.html">MITRE, CWE-117</a> - Improper Output Neutralization for Logs </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S5167">roslyn.sonaranalyzer.security.cs:S5167</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
constructing HTTP response headers based on tainted data could allow attackers to inject characters that would be interpreted as a new line in some
browsers. This could, for example, enable Cross-Site Scripting (XSS) attacks.</p>
<p>Most modern web application frameworks and servers mitigate this type of attack by default, but there might be rare cases where older versions are
still vulnerable. As a best practice, applications that use user provided data to construct the response header should always validate the data first.
Validation should be based on a whitelist.</p>
<h2>Noncompliant Code Example</h2>
<pre>
string value = Request.QueryString["value"];
Response.AddHeader("X-Header", value); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
string value = Request.QueryString["value"];
// Allow only alphanumeric characters
if (value == null || !Regex.IsMatch(value, "^[a-zA-Z0-9]+$"))
{
  throw new Exception("Invalid value");
}
Response.AddHeader("X-Header", value);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">OWASP Attack Category</a> - HTTP Response Splitting </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/113.html">MITRE, CWE-113</a> - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP
  Response Splitting') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S2076">roslyn.sonaranalyzer.security.cs:S2076</a>
					</td>
					<td>
						<details>
							<p>Applications that execute operating system commands or execute commands that interact with the underlying system should neutralize any
externally-provided values used in those commands. Failure to do so could allow an attacker to include input that executes unintended commands or
exposes sensitive data.</p>
<p>The mitigation strategy should be based on whitelisting of allowed characters or commands.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class CommandInjection : Controller
{
  // GET /CommandInjection/Run
  public IActionResult Run(string binary)
  {
    // If the value "/sbin/shutdown" is passed as binary and the web server is running as root,
    // then the machine running the web server will be shut down and become unavailable for future requests

    Process p = new Process();
    p.StartInfo.FileName = binary; // Noncompliant
    p.StartInfo.RedirectStandardOutput = true;
    p.Start();
    string output = p.StandardOutput.ReadToEnd();
    return Content(output);
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class CommandInjection : Controller
{
  // GET /CommandInjection/Run
  public IActionResult Run(string binary)
  {
    // Restrict to binaries within the current working directory whose name only contains letters
    if (binary == null || !Regex.IsMatch(binary, "^[a-zA-Z]+$"))
    {
      return BadRequest();
    }

    Process p = new Process();
    p.StartInfo.FileName = binary; // Now safe
    p.StartInfo.RedirectStandardOutput = true;
    p.Start();
    string output = p.StandardOutput.ReadToEnd();
    return Content(output);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/78">MITRE, CWE-78</a> - Improper Neutralization of Special Elements used in an OS Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/88">MITRE, CWE-88</a> - Argument Injection or Modification </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S5131">roslyn.sonaranalyzer.security.cs:S5131</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Endpoints reflecting
back tainted data could allow attackers to inject code that would eventually be executed in the user's browser. This could enable a wide range of
serious attacks like accessing/modifying sensitive information or impersonating other users.</p>
<p>Typically, the solution is one of the following:</p>
<ul>
  <li> Validate user provided data based on a whitelist and reject input that's not whitelisted. </li>
  <li> Sanitize user provided data from any characters that can be used for malicious purposes. </li>
  <li> Encode user provided data being reflected as output. Adjust the encoding to the output context so that, for example, HTML encoding is used for
  HTML content, HTML attribute encoding is used for attribute values, and JavaScript encoding is used for server-generated JavaScript. </li>
</ul>
<p>When sanitizing or encoding data, it is recommended to only use libraries specifically designed for security purposes. Also, make sure that the
library you are using is being actively maintained and is kept up-to-date with the latest discovered vulnerabilities.</p>
<h2>Noncompliant Code Example</h2>
<pre>
string name = Request.QueryString["name"];
Response.Write("Hello " + name); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
string name = Request.QueryString["name"];
name = System.Web.Security.AntiXss.AntiXssEncoder.HtmlEncode(name, true);
Response.Write("Hello " + name);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md">OWASP Cheat
  Sheet</a> - XSS Prevention Cheat Sheet </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/80.html">MITRE, CWE-80</a> - Improper Neutralization of Script-Related HTML Tags in a Web Page
  (Basic XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/81.html">MITRE, CWE-81</a> - Improper Neutralization of Script in an Error Message Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/82.html">MITRE, CWE-82</a> - Improper Neutralization of Script in Attributes of IMG Tags in a
  Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/83.html">MITRE, CWE-83</a> - Improper Neutralization of Script in Attributes in a Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/84.html">MITRE, CWE-84</a> - Improper Neutralization of Encoded URI Schemes in a Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/85.html">MITRE, CWE-85</a> - Doubled Character XSS Manipulations </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/86.html">MITRE, CWE-86</a> - Improper Neutralization of Invalid Characters in Identifiers in
  Web Pages </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/87.html">MITRE, CWE-87</a> - Improper Neutralization of Alternate XSS Syntax </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S5144">roslyn.sonaranalyzer.security.cs:S5144</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. A remote server
making requests to URLs based on tainted data could enable attackers to make arbitrary requests to the internal network or to the local file
system.</p>
<p>The problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not send requests based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public class SSRF : Controller
{
  public IActionResult Test(string url)
  {
    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); // Noncompliant
    // ...
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class SSRF : Controller
{
  private string[] whiteList = { "https://www.sonarsource.com" };

  public IActionResult Test(string url)
  {
    // Match the incoming URL against a whitelist
    if (!whiteList.Contains(url))
    {
      return BadRequest();
    }

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
    // ...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">OWASP Attack Category</a> - Server Side Request Forgery </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/918.html">MITRE, CWE-918</a> - Server-Side Request Forgery (SSRF) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=roslyn.sonaranalyzer.security.cs:S2083">roslyn.sonaranalyzer.security.cs:S2083</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Constructing file
system paths directly from tainted data could enable an attacker to inject specially crafted values, such as <code>'../'</code>, that change the
initial path and, when accessed, resolve to a path on the filesystem where the user should normally not have access.</p>
<p>A successful attack might give an attacker the ability to read, modify, or delete sensitive information from the file system and sometimes even
execute arbitrary operating system commands. This is often referred to as a "path traversal" or "directory traversal" attack.</p>
<p>The mitigation strategy should be based on the whitelisting of allowed paths or characters.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class PathTraversal : Controller
{
  // GET /PathTraversal/Authenticate
  public IActionResult Authenticate(string user)
  {
    bool userExists = System.IO.File.Exists("/home/" + user); // Noncompliant

    // If the special value "../bin" is passed as user, authentication is bypassed
    // Indeed, if it passed as a user, the path becomes:
    // /bin
    // which exists on most Linux / BSD / Mac OS distributions

    return Content(userExists ? "success" : "fail");
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class PathTraversal : Controller
{
  // GET /PathTraversal/Authenticate
  public IActionResult Authenticate(string user)
  {
    // Restrict the username to letters and digits only
    if (!Regex.IsMatch(user, "^[a-zA-Z0-9]+$"))
    {
        return BadRequest();
    }

    bool userExists = System.IO.File.Exists("/home/" + user); // Now safe
    return Content(userExists ? "success" : "fail");
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/22">MITRE, CWE-22</a> - Improper Limitation of a Pathname to a Restricted Directory ('Path
  Traversal') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/23">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/36">MITRE, CWE-36</a> - Absolute Path Traversal </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/99">MITRE, CWE-99</a> - Improper Control of Resource Identifiers ('Resource Injection') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5146">phpsecurity:S5146</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
performing HTTP redirects based on tainted data could enable an attacker to redirect users to a malicious site to, for example, steal login
credentials.</p>
<p>This problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not perform redirects based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
$url = $this-&gt;request-&gt;getQuery("url");
return $this-&gt;redirect($url); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$whitelist = array(
  "https://www.sonarsource.com/"
);
$url = $this-&gt;request-&gt;getQuery("url");
if (in_array($url, $whitelist)) {
  return $this-&gt;redirect($url);
} else {
  throw new ForbiddenException();
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/601.html">MITRE, CWE-601</a> - URL Redirection to Untrusted Site ('Open Redirect') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5145">phpsecurity:S5145</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads or cookies, should always be considered untrusted and tainted. Applications logging
tainted data could enable an attacker to inject characters that would break the log file pattern. This could be used to block monitors and SIEM
(Security Information and Event Management) systems from detecting other malicious events.</p>
<p>This problem could be mitigated by sanitizing the user provided data before logging it.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$data = $_GET["data"];
error_log($data); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$data = $_GET["data"];
$badchars = array("\n", "\r", "\t");
$safedata = str_replace($badchars, "", $data);
error_log($safedata);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Logging_Cheat_Sheet">OWASP Cheat Sheet</a> - Logging </li>
  <li> <a href="https://www.owasp.org/index.php/Log_Injection">OWASP Attack Category</a> - Log Injection </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A1-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/117.html">MITRE, CWE-117</a> - Improper Output Neutralization for Logs </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5167">phpsecurity:S5167</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications
constructing HTTP response headers based on tainted data could allow attackers to inject characters that would be interpreted as a new line in some
browsers. This could, for example, enable Cross-Site Scripting (XSS) attacks.</p>
<p>Most modern web application frameworks and servers mitigate this type of attack by default, but there might be rare cases where older versions are
still vulnerable. As a best practice, applications that use user provided data to construct the response header should always validate the data first.
Validation should be based on a whitelist.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$value = $_GET["value"];
header("X-Header: $value"); // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$value = $_GET["value"];
if (ctype_alnum($value)) {
  header("X-Header: $value"); // Compliant
} else {
  // Error
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">OWASP Attack Category</a> - HTTP Response Splitting </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/113.html">MITRE, CWE-113</a> - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP
  Response Splitting') </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5131">phpsecurity:S5131</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Endpoints reflecting
back tainted data could allow attackers to inject code that would eventually be executed in the user's browser. This could enable a wide range of
serious attacks like accessing/modifying sensitive information or impersonating other users.</p>
<p>Typically, the solution is one of the following:</p>
<ul>
  <li> Validate user provided data based on a whitelist and reject input that's not whitelisted. </li>
  <li> Sanitize user provided data from any characters that can be used for malicious purposes. </li>
  <li> Encode user provided data being reflected as output. Adjust the encoding to the output context so that, for example, HTML encoding is used for
  HTML content, HTML attribute encoding is used for attribute values, and JavaScript encoding is used for server-generated JavaScript. </li>
</ul>
<p>When sanitizing or encoding data, it is recommended to only use libraries specifically designed for security purposes. Also, make sure that the
library you are using is being actively maintained and is kept up-to-date with the latest discovered vulnerabilities.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$name = $_GET["name"];
echo "Welcome $name"; // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
$name = $_GET["name"];
$safename = htmlspecialchars($name);
echo "Welcome $safename";
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md">OWASP Cheat
  Sheet</a> - XSS Prevention Cheat Sheet </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)">OWASP Top 10 2017 Category A7</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/79.html">MITRE, CWE-79</a> - Improper Neutralization of Input During Web Page Generation
  ('Cross-site Scripting') </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/80.html">MITRE, CWE-80</a> - Improper Neutralization of Script-Related HTML Tags in a Web Page
  (Basic XSS) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/81.html">MITRE, CWE-81</a> - Improper Neutralization of Script in an Error Message Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/82.html">MITRE, CWE-82</a> - Improper Neutralization of Script in Attributes of IMG Tags in a
  Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/83.html">MITRE, CWE-83</a> - Improper Neutralization of Script in Attributes in a Web Page
  </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/84.html">MITRE, CWE-84</a> - Improper Neutralization of Encoded URI Schemes in a Web Page </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/85.html">MITRE, CWE-85</a> - Doubled Character XSS Manipulations </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/86.html">MITRE, CWE-86</a> - Improper Neutralization of Invalid Characters in Identifiers in
  Web Pages </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/87.html">MITRE, CWE-87</a> - Improper Neutralization of Alternate XSS Syntax </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=phpsecurity:S5144">phpsecurity:S5144</a>
					</td>
					<td>
						<details>
							<p>User provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. A remote server
making requests to URLs based on tainted data could enable attackers to make arbitrary requests to the internal network or to the local file
system.</p>
<p>The problem could be mitigated in any of the following ways:</p>
<ul>
  <li> Validate the user provided data based on a whitelist and reject input not matching. </li>
  <li> Redesign the application to not send requests based on user provided data. </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
$url = $_GET["url"];
$resp = file_get_contents($url); // Noncompliant
// ...
</pre>
<h2>Compliant Solution</h2>
<pre>
$whitelist = array(
  "https://www.sonarsource.com"
);
$url = $_GET["url"];
if (in_array($url, $whitelist)) {
  $resp = file_get_contents($url);
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">OWASP Attack Category</a> - Server Side Request Forgery </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/918.html">MITRE, CWE-918</a> - Server-Side Request Forgery (SSRF) </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/641.html">MITRE, CWE-641</a> - Improper Restriction of Names for Files and Other Resources
  </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cpp:S5184">cpp:S5184</a>
					</td>
					<td>
						<details>
							<p>The RAII idiom associates the lifetime of a resource with the lifetime of an object: The resource is acquired when the object is created, and
released when it is destroyed.</p>
<p>If the object that controls the resource lifetime is a temporary, chances are that it will get destroyed while the resource should still be in use,
leading to resource corruption. This rules detects temporaries that look like RAII objects.</p>
<h2>Noncompliant Code Example</h2>
<pre>
void f() {
  scoped_lock{myMutex}; // Non compliant. The mutex will be locked then immediately unlocked
  protectedCode(); // This code is not protected by the mutex
}
</pre>
<h2>Compliant Solution</h2>
<pre>
void f() {
  scoped_lock lock{myMutex}; // Compliant
  protectedCode();
  // The mutex is correctly released at this point
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es84-dont-try-to-declare-a-local-variable-with-no-name">C++ Core
  Guidelines ES.84</a> - Don’t (try to) declare a local variable with no name </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=ruby:S2068">ruby:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=scala:S2068">scala:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:S3394">cobol:S3394</a>
					</td>
					<td>
						<details>
							<p>The <code>ACCEPT</code> keyword does no editing or error checking of the data it stores, therefore its use can be dangerous. For this reason,
<code>ACCEPT</code> should be avoided. </p>
<h2>Noncompliant Code Example</h2>
<pre>
 01 USER-INPUT PIC X(4).

  GET-USER-INPUT.
       MOVE 'N' TO WS-NUMERIC.
       PERFORM UNTIL WS-NUMERIC = 'Y'
           DISPLAY 'ENTER YOUR 4 DIGIT RECORD NUMBER: ' NO ADVANCING
           ACCEPT USER-RECORD *&gt; Noncompliant
</pre>
<h2>Exceptions</h2>
<p>This rule ignores uses of <code>ACCEPT FROM</code> with date/time-related inputs.</p>
<h2>See</h2>
<ul>
  <li> OWASP Top 10 2017 Category A1 - Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:SQL.SelectWithNoWhereClauseCheck">cobol:SQL.SelectWithNoWhereClauseCheck</a>
					</td>
					<td>
						<details>
							<p>Although the <code>WHERE</code> condition is optional in a <code>SELECT</code> statement, for performance and security reasons, a
<code>WHERE</code> clause should always be specified to prevent reading the whole table.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SELECT * FROM db_persons INTO us_persons
</pre>
<h2>Compliant Solution</h2>
<pre>
SELECT * FROM db_persons INTO us_persons WHERE country IS 'US'
</pre>
<h2>Exceptions</h2>
<p>Not having a WHERE clause is acceptable in read-only cursors as results are generally sorted and it is possible to stop processing in the
middle.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:SQL.DynamicSqlCheck">cobol:SQL.DynamicSqlCheck</a>
					</td>
					<td>
						<details>
							<p>It is a bad practice to use Dynamic SQL. It differs from static embedded SQL in that part or all of the actual SQL commands may be stored in a host
variable that is built on the fly during execution of the program. In the extreme case, the SQL commands are generated in their entirety by the
application program at run time. While dynamic SQL is more flexible than static embedded SQL, it does require additional overhead and is much more
difficult to understand and to maintain.</p>
<p>Moreover, dynamic SQL may expose the application to SQL injection vulnerabilities.</p>
<p>This rule raises an issue when <code>PREPARE</code> or <code>EXECUTE IMMEDIATE</code> is used.</p>
<h2>Noncompliant Code Example</h2>
<pre>
EXEC SQL PREPARE SEL INTO :SQLDA FROM :STMTBUF END-EXEC.
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/89.html">MITRE, CWE-89</a> - SQL Injection </li>
  <li> OWASP Top 10 2017 Category A1 - Injection </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat1">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:S1685">cobol:S1685</a>
					</td>
					<td>
						<details>
							<p>Debug statements (ones with 'D' or 'd' in the indicator area) should not be executed in production, but the <code>WITH DEBUGGING MODE</code> clause
activates all debug lines, which could expose sensitive information to attackers. Therefore the <code>WITH DEBUGGING MODE</code> clause should be
removed.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE.
</pre>
<h2>Compliant Solution</h2>
<pre>
SOURCE-COMPUTER. IBM-370.
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
  <li> OWASP Top 10 2017 Category A3 - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:S1686">cobol:S1686</a>
					</td>
					<td>
						<details>
							<p>Defining a subprogram to be called at runtime is possible but ill-advised. This extremely powerful feature can quite easily be misused, and even
when used correctly, it highly increases the overall complexity of the program, and makes it impossible before runtime to know exactly what will be
executed. Therefore defining the subprogram to be called at runtime is a feature that should be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
MOVE SOMETHING TO MY_SUBPROG.
...
CALL MY_SUBPROG.
</pre>
<h2>Compliant Solution</h2>
<pre>
01 MY_SUBPROG PIC X(10) VALUE "SUB123".
....
CALL MY_SUBPROG.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cobol:COBOL.DisplayStatementUsageCheck">cobol:COBOL.DisplayStatementUsageCheck</a>
					</td>
					<td>
						<details>
							<p>The <code>DISPLAY</code> statement outputs data to standard out or some other destination and could reveal sensitive information. Therefore, it
should be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DISPLAY "hello world"  *&gt; Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
  <li> OWASP Top 10 2017 Category A3 - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=plsql:MaskedExceptionCheck">plsql:MaskedExceptionCheck</a>
					</td>
					<td>
						<details>
							<p>When exceptions occur, it is usually a bad idea to simply ignore them. Instead, it is better to handle them properly, or at least to log them.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SET SERVEROUTPUT ON

DECLARE
  d VARCHAR2(1);
BEGIN
  SELECT dummy INTO d FROM DUAL WHERE dummy = 'Y'; -- Will raise NO_DATA_FOUND
  DBMS_OUTPUT.PUT_LINE('d = ' || d);
EXCEPTION
  WHEN NO_DATA_FOUND THEN -- Noncompliant, did we really want to mask this exception?
    NULL;
END;
/
</pre>
<h2>Compliant Solution</h2>
<pre>
SET SERVEROUTPUT ON

DECLARE
  d VARCHAR2(1);
BEGIN
  SELECT dummy INTO d FROM DUAL WHERE dummy = 'Y'; -- Will raise NO_DATA_FOUND
  DBMS_OUTPUT.PUT_LINE('d = ' || d);
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    DBMS_OUTPUT.PUT_LINE('Error: No data found');
END;
/
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/391.html">MITRE, CWE-391</a> - Unchecked Error Condition </li>
  <li> OWASP Top 10 2017 Category A10 - Insufficient Logging &amp; Monitoring </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=typescript:S2068">typescript:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>Noncompliant Code Example</h2>
<pre>
const password = "asdasd";

let my_pwd;
my_pwd = "qwerewt";

login({ passwd: "zxvxcv"});

const url = "https://example.com?password=hl2OAIXXZ60";
</pre>
<h2>Compliant Solution</h2>
<pre>
const password = loadCredentials();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=typescript:S1525">typescript:S1525</a>
					</td>
					<td>
						<details>
							<p>The debugger statement can be placed anywhere in procedures to suspend execution. Using the debugger statement is similar to setting a breakpoint
in the code. By definition such statement must absolutely be removed from the source code to prevent any unexpected behavior or added vulnerability to
attacks in production.</p>
<h2>Noncompliant Code Example</h2>
<pre>
for (i = 1; i&lt;5; i++) {
  // Print i to the Output window.
  Debug.write("loop index is " + i);
  // Wait for user to resume.
  debugger;
}
</pre>
<h2>Compliant Solution</h2>
<pre>
for (i = 1; i&lt;5; i++) {
  // Print i to the Output window.
  Debug.write("loop index is " + i);
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
  <li> OWASP Top 10 2017 Category A3 - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=swift:S2068">swift:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<p>It's recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", ...</p>
<h2>Noncompliant Code Example</h2>
<pre>
var post:NSString = "username=Steve&amp;password=123456"  // Noncompliant
var postData:NSData = post.dataUsingEncoding(NSASCIIStringEncoding)!
//...
var request:NSMutableURLRequest = NSMutableURLRequest(URL: url)
request.HTTPBody = postData
//...
var urlData: NSData? = NSURLConnection.sendSynchronousRequest(request, returningResponse:&amp;response, error:&amp;reponseError)
</pre>
<h2>Compliant Solution</h2>
<pre>
var post:NSString = "username=\(getEncryptedUser())&amp;password=\(getEncryptedPass())"
var postData:NSData = post.dataUsingEncoding(NSASCIIStringEncoding)!
//...
var request:NSMutableURLRequest = NSMutableURLRequest(URL: url)
request.HTTPBody = postData
//...
var urlData: NSData? = NSURLConnection.sendSynchronousRequest(request, returningResponse:&amp;response, error:&amp;reponseError)
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=swift:S2070">swift:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>Consider using safer alternatives, such as SHA-256, or SHA-3.</p>
<h2>Noncompliant Code Example</h2>
<pre>
  var hash = MD5() // Noncompliant
  "123".sha1() // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
  "123".sha512()
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> OWASP Top 10 2017 Category A6 - Security Misconfiguration </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=objc:S1079">objc:S1079</a>
					</td>
					<td>
						<details>
							<p>The <code>%s</code> placeholder is used to read a word into a string.</p>
<p>By default, there is no restriction on the length of that word, and the developer is required to pass a sufficiently large buffer for storing
it.</p>
<p>No matter how large the buffer is, there will always be a longer word.</p>
<p>Therefore, programs relying on <code>%s</code> are vulnerable to buffer overflows.</p>
<p>A field width specifier can be used together with the <code>%s</code> placeholder to limit the number of bytes which will by written to the
buffer.</p>
<p>Note that an additional byte is required to store the null terminator.</p>
<h2>Noncompliant Code Example</h2>
<pre>
char buffer[10];
scanf("%s", buffer);      // Noncompliant - will overflow when a word longer than 9 characters is entered
</pre>
<h2>Compliant Solution</h2>
<pre>
char buffer[10];
scanf("%9s", buffer);     // Compliant - will not overflow
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=c:S1079">c:S1079</a>
					</td>
					<td>
						<details>
							<p>The <code>%s</code> placeholder is used to read a word into a string.</p>
<p>By default, there is no restriction on the length of that word, and the developer is required to pass a sufficiently large buffer for storing
it.</p>
<p>No matter how large the buffer is, there will always be a longer word.</p>
<p>Therefore, programs relying on <code>%s</code> are vulnerable to buffer overflows.</p>
<p>A field width specifier can be used together with the <code>%s</code> placeholder to limit the number of bytes which will by written to the
buffer.</p>
<p>Note that an additional byte is required to store the null terminator.</p>
<h2>Noncompliant Code Example</h2>
<pre>
char buffer[10];
scanf("%s", buffer);      // Noncompliant - will overflow when a word longer than 9 characters is entered
</pre>
<h2>Compliant Solution</h2>
<pre>
char buffer[10];
scanf("%9s", buffer);     // Compliant - will not overflow
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cpp:S1079">cpp:S1079</a>
					</td>
					<td>
						<details>
							<p>The <code>%s</code> placeholder is used to read a word into a string.</p>
<p>By default, there is no restriction on the length of that word, and the developer is required to pass a sufficiently large buffer for storing
it.</p>
<p>No matter how large the buffer is, there will always be a longer word.</p>
<p>Therefore, programs relying on <code>%s</code> are vulnerable to buffer overflows.</p>
<p>A field width specifier can be used together with the <code>%s</code> placeholder to limit the number of bytes which will by written to the
buffer.</p>
<p>Note that an additional byte is required to store the null terminator.</p>
<h2>Noncompliant Code Example</h2>
<pre>
char buffer[10];
scanf("%s", buffer);      // Noncompliant - will overflow when a word longer than 9 characters is entered
</pre>
<h2>Compliant Solution</h2>
<pre>
char buffer[10];
scanf("%9s", buffer);     // Compliant - will not overflow
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/120">MITRE, CWE-120</a> - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
  </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/676">MITRE, CWE-676</a> - Use of Potentially Dangerous Function </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat2">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=apex:S2068">apex:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
String password = "xxxx"; // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
String password = retrievePassword();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=plsql:S2070">plsql:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.</p>
<p>Consider using safer alternatives, such as SHA-256, or SHA-3.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DBMS_CRYPTO.Hash(str, HASH_MD4);

DBMS_CRYPTO.Hash(str, HASH_MD5);

DBMS_CRYPTO.Hash(str, HASH_SH1);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> OWASP Top 10 2017 Category A6 - Security Misconfiguration </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="http://shattered.io/">SHAttered</a> - The first concrete collision attack against SHA-1. </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=plsql:SysOwnedFunctions">plsql:SysOwnedFunctions</a>
					</td>
					<td>
						<details>
							<p>Some Oracle packages contain powerful SYS-owned functions that can be used to perform malicious operations. For instance,
<code>DBMS_SYS_SQL.PARSE_AS_USER</code> can be used to execute a statement as another user.</p>
<p>Most programs do not need those functions and this rule helps identify them in order to prevent security risks.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DECLARE
  c INTEGER;
  sqltext VARCHAR2(100) := 'ALTER USER system IDENTIFIED BY hacker'; -- Might be injected by the user
BEGIN
  c := SYS.DBMS_SYS_SQL.OPEN_CURSOR();                               -- Noncompliant

   -- Will change 'system' user's password to 'hacker'
  SYS.DBMS_SYS_SQL.PARSE_AS_USER(c, sqltext, DBMS_SQL.NATIVE, UID);  -- Non-Compliant

  SYS.DBMS_SYS_SQL.CLOSE_CURSOR(c);                                  -- Noncompliant
END;
/
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/269.html">MITRE, CWE-269</a> - Improper Privilege Management </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/270.html">MITRE, CWE-270</a> - Privilege Context Switching Error </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=plsql:S2278">plsql:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
PLS_INTEGER := DBMS_CRYPTO.ENCRYPT_DES
                           + DBMS_CRYPTO.CHAIN_CBC
                           + DBMS_CRYPTO.PAD_PKCS5;
</pre>
<h2>Compliant Solution</h2>
<pre>
PLS_INTEGER := DBMS_CRYPTO.ENCRYPT_AES256
                           + DBMS_CRYPTO.CHAIN_CBC
                           + DBMS_CRYPTO.PAD_PKCS5;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> OWASP Top 10 2017 Category A6 - Security Misconfiguration </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=kotlin:S2068">kotlin:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
val params = "password=xxxx" // Noncompliant
val writer = OutputStreamWriter(getOutputStream())
writer.write(params)
writer.flush()
...
val password = "xxxx" // Noncompliant
...
</pre>
<h2>Compliant Solution</h2>
<pre>
val params = "password=${retrievePassword()}"
val writer = OutputStreamWriter(getOutputStream())
writer.write(params)
writer.flush()
...
val password = retrievePassword()
...
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S1492">abap:S1492</a>
					</td>
					<td>
						<details>
							<p>Although the <code>WHERE</code> condition is optional in a <code>SELECT</code> statement, for performance and security reasons, a
<code>WHERE</code> clause should always be specified to prevent reading the whole table.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SELECT * FROM db_persons INTO us_persons.
</pre>
<h2>Compliant Solution</h2>
<pre>
SELECT * FROM db_persons INTO us_persons WHERE country IS 'US'.
</pre>
<h2>Exceptions</h2>
<p><code>SELECT SINGLE</code> and <code>UP TO 1 ROWS</code> result in only one record being read, so such <code>SELECT</code>s are ignored by this
rule.</p>
<pre>
SELECT SINGLE * FROM db_persons INTO us_persons.

SELECT * FROM db_persons UP TO 1 ROWS INTO us_persons.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=abap:S1674">abap:S1674</a>
					</td>
					<td>
						<details>
							<p>Leaving a <code>CATCH</code> block empty means that the exception in question is neither handled nor passed forward to callers for handling at a
higher level. Suppressing errors rather than handling them could lead to unpredictable system behavior and should be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
  try.
    if ABS( NUMBER ) &gt; 100.
      write / 'Number is large'.
    endif.
    catch CX_SY_ARITHMETIC_ERROR into OREF.
  endtry.
</pre>
<h2>Compliant Solution</h2>
<pre>
  try.
    if ABS( NUMBER ) &gt; 100.
      write / 'Number is large'.
    endif.
  catch CX_SY_ARITHMETIC_ERROR into OREF.
    write / OREF-&gt;GET_TEXT( ).
  endtry.
</pre>
<h2>Exceptions</h2>
<p>When a block contains a comment, it is not considered to be empty.</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/391">MITRE, CWE-391</a> - Unchecked Error Condition </li>
  <li> OWASP Top 10 2017 Category A10 - Insufficient Logging &amp; Monitoring </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=csharpsquid:S1104">csharpsquid:S1104</a>
					</td>
					<td>
						<details>
							<p>Public fields in public classes do not respect the encapsulation principle and has three main disadvantages:</p>
<ul>
  <li> Additional behavior such as validation cannot be added. </li>
  <li> The internal representation is exposed, and cannot be changed afterwards. </li>
  <li> Member values are subject to change from anywhere in the code and may not meet the programmer's assumptions. </li>
</ul>
<p>By using private fields and public properties (set and get), unauthorized modifications are prevented. Properties also benefit from additional
protection (security) features such as Link Demands.</p>
<p>Note that due to optimizations on simple properties, public fields provide only very little performance gain.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class Foo
{
    public int instanceData = 32; // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class Foo
{
    private int instanceData = 32;

    public int InstanceData
    {
        get { return instanceData; }
	set { instanceData = value ; }
    }
}
</pre>
<h2>Exceptions</h2>
<p>Fields marked as <code>readonly</code> or <code>const</code> are ignored by this rule.</p>
<p>Fields inside classes or structs annotated with the <code>StructLayoutAttribute</code> are ignored by this rule.</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/493.html">MITRE, CWE-493</a> - Critical Public Variable Without Final Modifier </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1465">flex:S1465</a>
					</td>
					<td>
						<details>
							<p>A <code>LocalConnection</code> object is used to invoke a method in another <code>LocalConnection</code> object, either within a single SWF file or
between multiple SWF files. This kind of local connection should be authorized only when the origin (domain) of the other Flex applications is
perfectly defined. </p>
<h2>Noncompliant Code Example</h2>
<pre>
localConnection.allowDomain("*");
</pre>
<h2>Compliant Solution</h2>
<pre>
localConnection.allowDomain("www.myDomain.com");
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1466">flex:S1466</a>
					</td>
					<td>
						<details>
							<p>The Security.exactSettings value should remain set at the default value of true. Setting this value to false could make the SWF vulnerable to
cross-domain attacks.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Security.exactSettings = false;
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=flex:S1468">flex:S1468</a>
					</td>
					<td>
						<details>
							<p>Calling Security.allowDomain("*") lets any domain cross-script into the domain of this SWF and exercise its functionality.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Security.allowDomain("*");
</pre>
<h2>Compliant Solution</h2>
<pre>
Security.allowDomain("www.myDomain.com");
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=go:S1313">go:S1313</a>
					</td>
					<td>
						<details>
							<p>Hardcoding an IP address into source code is a bad idea for several reasons:</p>
<ul>
  <li> a recompile is required if the address changes </li>
  <li> it forces the same address to be used in every environment (dev, sys, qa, prod) </li>
  <li> it places the responsibility of setting the value to use in production on the shoulders of the developer </li>
  <li> it allows attackers to decompile the code and thereby discover a potentially sensitive address </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
var (
  ip   = "127.0.0.1"
  port = 3333
)

SocketClient(ip, port)
</pre>
<h2>Compliant Solution</h2>
<pre>
config, err := ReadConfig("properties.ini")

ip := config["ip"]
port := config["ip"]

SocketClient(ip, port)
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=go:S2068">go:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
strings, and for variable names that match any of the patterns from the provided list.</p>
<h2>Noncompliant Code Example</h2>
<pre>
func connect()  {
  user := "root"
  myPassword := "supersecret" // Noncompliant

  url := "login=" + user + "&amp;passwd=" + myPassword
}
</pre>
<h2>Compliant Solution</h2>
<pre>
func connect()  {
  user := getEncryptedUser()
  myPassword := getEncryptedPass() // Compliant

  url := "login=" + user + "&amp;passwd=" + myPassword
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> OWASP Top 10 2017 Category A2 - Broken Authentication </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:ClassVariableVisibilityCheck">squid:ClassVariableVisibilityCheck</a>
					</td>
					<td>
						<details>
							<p>Public class variable fields do not respect the encapsulation principle and has three main disadvantages:</p>
<ul>
  <li> Additional behavior such as validation cannot be added. </li>
  <li> The internal representation is exposed, and cannot be changed afterwards. </li>
  <li> Member values are subject to change from anywhere in the code and may not meet the programmer's assumptions. </li>
</ul>
<p>By using private attributes and accessor methods (set and get), unauthorized modifications are prevented.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyClass {

  public static final int SOME_CONSTANT = 0;     // Compliant - constants are not checked

  public String firstName;                       // Noncompliant

}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class MyClass {

  public static final int SOME_CONSTANT = 0;     // Compliant - constants are not checked

  private String firstName;                      // Compliant

  public String getFirstName() {
    return firstName;
  }

  public void setFirstName(String firstName) {
    this.firstName = firstName;
  }

}
</pre>
<h2>Exceptions</h2>
<p>Because they are not modifiable, this rule ignores <code>public final</code> fields.</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/493.html">MITRE, CWE-493</a> - Critical Public Variable Without Final Modifier </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1444">squid:S1444</a>
					</td>
					<td>
						<details>
							<p>There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a
state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to
<code>null</code>. </p>
<h2>Noncompliant Code Example</h2>
<pre>
public class Greeter {
  public static Foo foo = new Foo();
  ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/500.html">MITRE, CWE-500</a> - Public Static Field Not Marked Final </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QQBqAQ">CERT OBJ10-J.</a> - Do not use public static nonfinal fields </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2384">squid:S2384</a>
					</td>
					<td>
						<details>
							<p>Mutable objects are those whose state can be changed. For instance, an array is mutable, but a String is not. Mutable class members should never be
returned to a caller or accepted and stored directly. Doing so leaves you vulnerable to unexpected changes in your class state.</p>
<p>Instead use an unmodifiable <code>Collection</code> (via <code>Collections.unmodifiableCollection</code>,
<code>Collections.unmodifiableList</code>, ...) or make a copy of the mutable object, and store or return the copy instead.</p>
<p>This rule checks that arrays, collections and Dates are not stored or returned directly.</p>
<h2>Noncompliant Code Example</h2>
<pre>
class A {
  private String [] strings;

  public A () {
    strings = new String[]{"first", "second"};
  }

  public String [] getStrings() {
    return strings; // Noncompliant
  }

  public void setStrings(String [] strings) {
    this.strings = strings;  // Noncompliant
  }
}

public class B {

  private A a = new A();  // At this point a.strings = {"first", "second"};

  public void wreakHavoc() {
    a.getStrings()[0] = "yellow";  // a.strings = {"yellow", "second"};
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
class A {
  private String [] strings;

  public A () {
    strings = new String[]{"first", "second"};
  }

  public String [] getStrings() {
    return strings.clone();
  }

  public void setStrings(String [] strings) {
    this.strings = strings.clone();
  }
}

public class B {

  private A a = new A();  // At this point a.strings = {"first", "second"};

  public void wreakHavoc() {
    a.getStrings()[0] = "yellow";  // a.strings = {"first", "second"};
  }
}

</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/374">MITRE, CWE-374</a> - Passing Mutable Objects to an Untrusted Method </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/375">MITRE, CWE-375</a> - Returning a Mutable Object to an Untrusted Caller </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/zQCuAQ">CERT, OBJ05-J.</a> - Do not return references to private mutable class members
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QIEVAQ">CERT, OBJ06-J.</a> - Defensively copy mutable inputs and mutable internal
  components </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/JQLEAw">CERT, OBJ13-J.</a> - Ensure that references to mutable objects are not exposed
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2386">squid:S2386</a>
					</td>
					<td>
						<details>
							<p>There is no good reason to have a mutable object as the <code>public</code> (by default), <code>static</code> member of an <code>interface</code>.
Such variables should be moved into classes and their visibility lowered. </p>
<p>Similarly, mutable <code>static</code> members of classes and enumerations which are accessed directly, rather than through getters and setters,
should be protected to the degree possible. That can be done by reducing visibility or making the field <code>final</code> if appropriate. </p>
<p>Note that making a mutable field, such as an array, <code>final</code> will keep the variable from being reassigned, but doing so has no effect on
the mutability of the internal state of the array (i.e. it doesn't accomplish the goal).</p>
<p>This rule raises issues for <code>public static</code> array, <code>Collection</code>, <code>Date</code>, and <code>awt.Point</code> members.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public interface MyInterface {
  public static String [] strings; // Noncompliant
}

public class A {
  public static String [] strings1 = {"first","second"};  // Noncompliant
  public static String [] strings2 = {"first","second"};  // Noncompliant
  public static List&lt;String&gt; strings3 = new ArrayList&lt;&gt;();  // Noncompliant
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/582.html">MITRE, CWE-582</a> - Array Declared Public, Final, and Static </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/607.html">MITRE, CWE-607</a> - Public Static Final Field References Mutable Object </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/rwBc">CERT, OBJ01-J.</a> - Limit accessibility of fields </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/JQLEAw">CERT, OBJ13-J.</a> - Ensure that references to mutable objects are not exposed
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3066">squid:S3066</a>
					</td>
					<td>
						<details>
							<p><code>enum</code>s are generally thought of as constant, but an <code>enum</code> with a <code>public</code> field or <code>public</code> setter is
not only non-constant, but also vulnerable to malicious code. Ideally fields in an <code>enum</code> are <code>private</code> and set in the
constructor, but if that's not possible, their visibility should be reduced as much as possible.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public enum Continent {

  NORTH_AMERICA (23, 24709000),
  // ...
  EUROPE (50, 39310000);

  public int countryCount;  // Noncompliant
  private int landMass;

  Continent(int countryCount, int landMass) {
    // ...
  }

  public void setLandMass(int landMass) {  // Noncompliant
    this.landMass = landMass;
  }
</pre>
<h2>Compliant Solution</h2>
<pre>
public enum Continent {

  NORTH_AMERICA (23, 24709000),
  // ...
  EUROPE (50, 39310000);

  private int countryCount;
  private int landMass;

  Continent(int countryCount, int landMass) {
    // ...
  }
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3374">squid:S3374</a>
					</td>
					<td>
						<details>
							<p>According to the Common Weakness Enumeration,</p>
<blockquote>
  If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the
  other. This decision might not correspond to the programmer's expectations...
</blockquote>
<p>In such a case, it is likely that the two forms should be combined. At the very least, one should be removed.</p>
<h2>Noncompliant Code Example</h2>
<pre>
&lt;form-validation&gt;
  &lt;formset&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;  &lt;!-- Noncompliant --&gt;
  &lt;/formset&gt;
&lt;/form-validation&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
&lt;form-validation&gt;
  &lt;formset&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;
  &lt;/formset&gt;
&lt;/form-validation&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/102.html">MITRE, CWE-102</a> - Struts: Duplicate Validation Forms </li>
  <li> <a href="https://www.owasp.org/index.php/Struts:_Duplicate_Validation_Forms#Struts:_Duplicate_Validation_Forms">OWASP, Improper Data
  Validation</a> - Struts: Duplicate Validation Forms </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=swift:S2278">swift:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
let cryptor = try Cryptor(operation: .encrypt, algorithm: .des, options: [.ecbMode], key: key, iv: []) // Noncompliant

let crypt = CkoCrypt2()
crypt.CryptAlgorithm = "3des" // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
let cryptor = try Cryptor(operation: .encrypt, algorithm: .aes, options: [.ecbMode], key: key, iv: [])

let crypt = CkoCrypt2()
crypt.CryptAlgorithm = "blowfish"
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> OWASP Top 10 2017 Category A6 - Security Misconfiguration </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=swift:S2950">swift:S2950</a>
					</td>
					<td>
						<details>
							<p>The access level defaults to <code>internal</code> if left unspecified. Since that doesn't make sense for most top-level declarations, access
levels should always be specified explicitly, even when <code>internal</code> is what's intended.</p>
<p>This rule raises an issue when the access level is not specified on any top-level declaration.</p>
<h2>Noncompliant Code Example</h2>
<pre>
class Foo {  // Noncompliant
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class Foo {
  // ...
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=typescript:S2228">typescript:S2228</a>
					</td>
					<td>
						<details>
							<p>Debug statements are always useful during development. But include them in production code - particularly in code that runs client-side - and you
run the risk of inadvertently exposing sensitive information, slowing down the browser, or even erroring-out the site for some users.</p>
<h2>Noncompliant Code Example</h2>
<pre>
console.log(password_entered); // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> OWASP Top 10 2017 Category A3 - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=Web:AvoidHtmlCommentCheck">Web:AvoidHtmlCommentCheck</a>
					</td>
					<td>
						<details>
							<p>Using HTML-style comments in a page that will be generated or interpolated server-side before being served to the user increases the risk of
exposing data that should be kept private. For instance, a developer comment or line of debugging information that's left in a page could easily (and
has) inadvertently expose:</p>
<ul>
  <li> Version numbers and host names </li>
  <li> Full, server-side path names </li>
  <li> Sensitive user data </li>
</ul>
<p>Because every other language has its own native comment format, there is no justification for using HTML-style comments in anything other than a
pure HTML or XML file.</p>
<h2>Noncompliant Code Example</h2>
<pre>
  &lt;%
      out.write("&lt;!-- ${username} --&gt;");  // Noncompliant
  %&gt;
      &lt;!-- &lt;% out.write(userId) %&gt; --&gt;  // Noncompliant
      &lt;!-- #{userPhone} --&gt;  // Noncompliant
      &lt;!-- ${userAddress} --&gt; // Noncompliant

      &lt;!-- Replace 'world' with name --&gt; // Noncompliant
      &lt;h2&gt;Hello world!&lt;/h2&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
      &lt;%-- Replace 'world' with name --%&gt;  // Compliant
      &lt;h2&gt;Hello world!&lt;/h2&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/615.html">MITRE, CWE-615</a> - Information Exposure Through Comments </li>
  <li> OWASP Top 10 2017 Category A3 - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
			</tbody>
		</table>
	</div>

	

	<script>
		var canvas = document.getElementById("vulnerabilitiesPieChart");
		var ctx = canvas.getContext("2d");

		var data = [ 
			3 ,
			1 ,
			0 ,
			2
		];
		var total = data.reduce(function (sum, n) {
			return sum + n;
		})
		var colors = ['#2c3e50', '#d43223', '#f39c12', '#319ddb'];

		for (var i = 0, lastend = 0; i < data.length; i++) {
			ctx.fillStyle = colors[i];
			ctx.beginPath();
			ctx.moveTo(canvas.width / 2, canvas.height / 2);
			ctx.arc(canvas.width / 2, canvas.height / 2, canvas.height / 2, lastend, lastend + (Math.PI * 2 * (data[i] /
				total)), false);
			ctx.lineTo(canvas.width / 2, canvas.height / 2);
			ctx.fill();
			lastend += Math.PI * 2 * (data[i] / total);
		}
	</script>

	
</body>

</html>
